Re: HSTS preload flaw

[Austin William Wright <[e-mail]>]

On Feb 9, 2020, at 20:19, Eric Mill <[e-mail]> wrote:
> 
> On Sun, Feb 9, 2020 at 6:51 PM Austin Wright <[e-mail] <mailto:[e-mail]>> 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?

Austin.