W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2020

Re: HSTS preload flaw

From: Austin William Wright <aaa@bzfx.net>
Date: Sun, 9 Feb 2020 23:28:42 -0700
Message-Id: <4E5E865B-27E8-4933-B413-29494817246F@bzfx.net>
Cc: Rob Sayre <sayrer@gmail.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
To: Eric Mill <eric@konklone.com>
On Feb 9, 2020, at 20:19, Eric Mill <eric@konklone.com> wrote:
> On Sun, Feb 9, 2020 at 6:51 PM Austin Wright <aaa@bzfx.net <mailto:aaa@bzfx.net>> wrote:
> If encrypted connections are important to you as a server operator, it seems the only foolproof way to avoid plaintext communication is don’t listen on port 80.
> Without getting into the overall issue, I just want to note for readers of the thread - server operators can't avoid plaintext communication by clients by not listening on port 80. Clients can attempt to initiate a connection to a hostname over port 80 whether or not the "real" server is listening on port 80, and that connection can be interfered with by a malicious network actor. That's why HSTS exists - to provide some kind of signal to the client that they should never bother even trying to make that connection.

This is correct, thanks for the correction. I should have noted this. Also, note how HSTS applies to all connections to a hostname, regardless of port number.

In an active (MITM) attack, the server operator doesn’t even have to be online, of course; the attacker will receive all connections to the intended host.

My comment is with regards to passive attacks where a server operator wants to avoid inadvertently accepting plaintext data: A Permanent Redirect would still allow the headers to be sent to the server (and the request body, if the client doesn’t follow 100-continue).

It seems to me if an attacker can get a victim to compose a sensitive request, but direct that request to an attacker-controlled scheme and port, why not an attacker-controlled host too, or any host not on an HSTS Preload list?

Received on Monday, 10 February 2020 06:28:48 UTC

This archive was generated by hypermail 2.4.0 : Monday, 10 February 2020 06:28:49 UTC