[aargh_aargh]

Honest question/thought - at this point where we have all HTTP requests for a site just redirecting everything to HTTPS, we use HSTS and browsers default to trying https when scheme is not given, why don't we just stop serving on port 80 altogether? Why even bother with HSTS?

[tetha]

I have a few internal services on which I like to crank transport security to 11. No port 80, only TLS 1.3, only modern ciphers. You'd be surprised how much confusion not opening port 80 caused across technical people. And I've learned a bunch of things about supported TLS versions and supported ciphers of windows server versions from this crusade.

And that's with experienced admins and developers. Doing this with our average B2B customer? Hah, oh dear.

[tptacek]

The answer to this question is interesting, and it's that not serving HTTP doesn't actually help. The attacker HTTPS contemplates controls whether victims see SYN+ACK packets in response to their 80/tcp SYNs. TCP itself isn't authenticated. So you need something "sticky" in the browser to remind it not to try 80/tcp, and thus risk being bamboozled by a MITM attacker.

[dxdm]

> The attacker HTTPS contemplates controls whether victims see SYN+ACK packets in response to their 80/tcp SYNs.

This informationally dense and adventurously worded sentence is the kind that you can only understand if you already understand it, it feels like. I certainly can't unpack it without getting my hiking gear on. Not this rainy morning, though, may the transport layer gods forgive me.

[vluft]

if an attacker is in the position to try to MITM TLS, they're in the position to just serve whatever they want on port 80 even if your server isn't doing that.

[tptacek]

They can't all be winners!

[dxdm]

Thanks for sending them on their way regardless. It does tend to move things forward.

[tptacek]

Like a good dose of dietary fiber.

[dspillett]

For new sites that is definitely practical. Modern versions of Chrom{e|ium} & Firefox (and other browsers based on them) have defaulted to HTTPS when the protocol is not specified. The only potential issue is if users do specify the protocol and leave the S out, it would be good for browsers to try HTTPS when HTTP fails (though only if it completely fails to connect).

[baobun]

> Modern versions of Chrom{e|ium} & Firefox (and other browsers based on them) have defaulted to HTTPS when the protocol is not specified.

This is not true but it would be nice if it was.

https://news.ycombinator.com/item?id=46443199

[dspillett]

Hmm. I am perhaps confusing announced plans, and the effect of the HSTS preload lists, with actually released changes to defaults.

I'll have to install some fresh VMs and see what behaviour I get out-of-the-box with no HSTS cache (and sites not on the preload lists) on various OSs, to correct my understanding.

[Ellipsis753]

Old links to your site might still be http - HSTS prevents that request being in the clear. Also, if you have a man-in-the-middle attack, it doesn't matter if you return a redirect or not as the attacker has already replaced your site with a phishing attack instead of a redirect. HSTS prevents this.

[RamRodification]

Your second example would also be prevented by just not serving on port 80 as the parent comment suggests, no?

[toast0]

A MITM can intercept the SYNs to port 80 and send their own SYN+ACK.

Not serving on port 80 means a passive viewer won't see any content, but if you were just serving a redirect, there's not much content to see.

IMHO, if you use HSTS preload and you prime HSTS by serving your favicon with https and HSTS, you can go ahead and serve your (unauthenticated) content with http. A modern browser will switch over to https; a MITM could fetch your https pages and return them over http; and you'll be accessible on ancient browsers that can't manage modern TLS.

[ycombinatrix]

No, not really. You can still be MITMed on port 80.

[RamRodification]

Right. Clients (web browsers) would have to stop using it too for it to work I guess.

[meindnoch]

>no?

No.

[ozim]

Just wait a bit and there will be some TLS denialism spawning here.

For a lot stuff on my local network I don’t want the hassle and there are loads of use cases in local networks for normal people to just have port 80 no certs on something like 192.x.x.x because there is no easy way to set up public certificates for that and I don’t want everything hostem on cloud - some stuff I want to still host for myself in my local network.

Corporations or companies should not do that - even internal networks should have proper certs and encryption but it also is not that easy.

Stuff sent over the internet for others to see should have TLS always because you don’t know where your packets travel.

[9029]

> For a lot stuff on my local network I don’t want the hassle and there are loads of use cases in local networks for normal people to just have port 80 no certs on something like 192.x.x.x because there is no easy way to set up public certificates for that and I don’t want everything hostem on cloud - some stuff I want to still host for myself in my local network.

Tbh I don't see what's hard about this. All you need is an A record pointing to your 192.x.x.x, acme capable dns host and a modern reverse proxy. You can even use a free ddns service if you want. Wouldn't bother with this for development, but anything hosted for longer than a few days absolutely yes. Imo not getting browser warnings is alone worth the few minutes it takes nowadays.

[dmitrygr]

“ All you need is an A record pointing to your 192.x.x.x, acme capable dns host and a modern reverse proxy”. That’s a LOT more than socket(), listen(), and accept().

[SahAssar]

> All you need is an A record pointing to your 192.x.x.x, acme capable dns host and a modern reverse proxy

And to distribute keys that allow those appliances to update the DNS records, to secure those keys, have an a way to install those keys (and update/rotate them), and make sure your DNS host is supported by your acme client.

[ozim]

XD

I can yeah it is easy but I have 20 years of experience.

I don’t want to spend time setting that up.

For less technically capable people you just lost them in first sentence.

[gucci-on-fleek]

> For a lot stuff on my local network I don’t want the hassle […] because there is no easy way to set up public certificates

Everything on my home network uses publicly-trusted certs from LE, including my router with only 8MB of flash and 128MB of memory. You need to use the DNS challenges if you don't want the services to be publicly accessible, but you can run ACME on nearly everything these days.

[ozim]

Neat part is that’s my local network and I don’t want to spend time doing that.

I’d much rather spend time arguing about it on HN.

That’s the neat part of “it is my time” and I want to use it the way I want.

It doesn’t apply to stuff I publish over the internet all personal pages blogs have https, that’s not negotiable.

[gucci-on-fleek]

Fair enough. The only reason that I bothered setting up HTTPS certificates in my home network was because I was using a domain where I had previously enabled HSTS. I was wasn't very enthusiastic about it when I first added the certificates, but once I figured it out, I appreciated seeing a little padlock when I logged in to my router. That's essentially the only benefit though, so I certainly don't blame you for not wanting to go through the effort to set it up.

[gwbas1c]

IMO: The right time to ask this question is when all browsers default to HTTPS; instead we should ask why browsers default to http instead of https.

IE: I just typed "google.com" into Brave and it made a request to http://google.com which responded with a 307 redirect to https://google.com, which then made a 301 redirect to https://www.google.com.

[hex-m]

Firefox, Safari, Chrome, Edge and even Brave have "HTTPS first" or "HTTPS by default" enabled out of the box. HTTP is only used as a fallback.

[baobun]

Why are you saying lies?

I just installed fresh chromium and firefox in a clean Linux VM and typed "google.com" (and a few others) in the URL bar with tcpdump running and they both initiated with TCP port 80. Can confirm that the https-only setting is disabled for both when looking in settings/preferences.

> HTTP is only used as a fallback.

Separately, using HTTP as fallback makes the whole thing mostly pointless security-wise. If an attacker can MitM port 80 it is very likely that they can also interfere with 443 to silently force a protocol downgrade. STRIPTLS.

SMTP STARTTLS has the same problem. ISPs and authorities have been known to harvest email traffic by the same technique.

We don't really need HSTS to address most scenarios. Just have browser not attempt http:// for addresses in the address bar unless explicitly specified. Have it try https:// without falling back to http://.

HTTPS-by-default with fallback is not a good default setting since it's vulnerable to the above attack. Strict HTTPS-only is not a good default setting since it prevents legitimate http traffic on internal networks. HSTS adds problematic edge-cases. It's hard to fathom that none of the major browser vendors seem to have figured out the obvious solution to just stop inferring http:// unless asked for.

[gwbas1c]

Really, the only time I use "http" is for running web services on my localhost for debugging, to connect to my router, and to connect to my NAS.

I'm not sure the best way to secure that situation. Unencrypted traffic that only stays on my own computer is a valid use case, and unencrypted traffic on my home network is about as risky as skinny dipping in your own back yard.

[gwbas1c]

Then why did mine do http first? Use the F12 screen to watch your browser resolve a domain that you type into the address bar.

[evanjrowley]

Microsoft Edge Version 142.0.3595.65 on macOS does not default to HTTPS, FWIW. Users accessing sites that do not redirect HTTP to HTTPS must specify the full URL, at least in my experience from 2024-2025.

[kiririn]

Even with default https etc, HSTS still adds some defence against MITM - browsers won’t let you even forcibly accept a self signed certificate

[AlotOfReading]

The number of MITM attacks that's thwarted for me remains zero, while sites forgetting to renew their certs despite setting HSTS is a fairly regular occurrence.

[zeeZ]

Not being able to access the web interface where you have to manually upload a new certificate due to HSTS and the old certificate having expired a couple hours ago...

[kiririn]

Yeah it’s more of an annoyance for sure. I only discovered it was a thing when intentionally MITMing a domain on my router

[Arbortheus]

It would be nice. Our security team started complaining that we serve a 301 redirect on port 80 for our website (just like 99.9% of websites do... sigh) and wanted port 80 shut down.

To appease them, I switched the redirect off in dev/staging, and soon enough even devs are having trouble accessing the site because they type 'website.com' and that can't resolve, only 'https://website.com' can.

(And before you say it, yes we use HSTS, but I presume there were some scenarios where that wasn't already cached/hit).