www: remove HSTS header from port 80

[Knight1]

Can not find a way to remove it. I would simply remove HSTS from the global.conf and make a new hsts.conf and include that in the Port 443 places.

[nils-wisiol]

Sounds good to me.

[Darkspirit]

Alternatively you could remove https://github.com/desec-io/desec-stack/blob/09459386bd18846d58b2453bb2a6c6160241db13/www/conf/sites-available/85-redirects.conf.var#L4-L16 and listen on port 443 only. desec.io is HSTS preloaded. Keeping port 80 open makes only sense for

• the period until you are HSTS preloaded (this will be fixed by Firefox and Chrome),
• unsupported/insecure browser versions like older Android browsers, but only if you expect that users manually type your domain into their address bar or manually type your domain (without https) into a chat app. I assume it's much more likely that they either use a search engine or copy a link into a chat.

[peterthomassen]

Good point. I just discussed closing port 80 with a friend, and he put forward the argument that it's not worth it if you loose even a small number of connections only (such as old devices). This argument would not make sense if there was a real downside to having port 80 open, of course.

But, what's the downside? Imagine, for example, you accidentally send your API token to port 80. If the port is closed, the TCP connection will not be established, and you will not actually send the token. Great! But against what sort of attacker does that defend? - If sending your token to port 80 is a problem, then you have an attacker who is on the line (MITM). However, if you have such an attacker, the attacker can intercept port 80 traffic, set up a fake service on port 80, and still receive your token. In other words, the attack scenario we're discussing isn't mitigated by closing port 80.

So, while there is a clear upside to having port 80 open (easing the transition for non HSTS-preload aware clients), what's the downside?

[Darkspirit]

Yes, this is more an idealistic question of trying it out and driving it forward or not.

Imagine, for example, you accidentally send your API token to port 80.

If legacy port 80 were closed, you could immediately notice your mistake and fix the configuration to not send API tokens to port 80 anymore. (Only browsers support HSTS preload.) This type of cleanup could defend such mistakes. It's nudging people into TLS and creating awareness.

If more people did this, it would probably be easier to lobby at Safari to implement "fallback to https" as well. (I haven't asked yet.) More demand creates a need to support it. If all three browser engines supported "fallback to https" because some people don't want to open port 80 anymore, nobody would need to open port 80 anymore until browsers are able to default to https. IMHO, it's also nice to close one legacy port for opening another one for HTTP/3 (QUIC) in the near future. ^^

[nils-wisiol]

But against what sort of attacker does that defend?

It defends against attackers that are only listening, as the client will never start to send HTTP. It's, of course, pointless if the attacker can accept connections.

As a minor side-effect, it also saves the processing, sending payloads and so on from a small number of connections that will be answered with redirect or 400 status anyway.

On the other hand, I imagine it will cause a number of "Your Service is Down Do Something!!11" emails.