[HN Gopher] HTTP Strict Transport Security (HSTS)
___________________________________________________________________
HTTP Strict Transport Security (HSTS)
Author : arunc
Score : 30 points
Date : 2025-12-29 08:14 UTC (1 days ago)
(HTM) web link (hstspreload.org)
(TXT) w3m dump (hstspreload.org)
| tialaramex wrote:
| I think we're probably at the endgame where ordinary people start
| to benefit from HTTPS-by-default. Ten years ago it was way too
| annoying for me to even suggest to my mother that she should have
| this, although I did use it myself because I understand the
| caveats, but today "We don't have HTTPS" either means you don't
| really support web browsers (e.g. some protocols deliberately are
| HTTP-based but don't use TLS and some even can't if they wanted
| to) or that the whole site is mothballed so if it didn't have TLS
| in 2015 it still doesn't today.
|
| As we transition ordinary users to HTTPS-by-default the HSTS
| feature loses importance. The target audience for HSTS isn't me,
| or the package management software I run, or some Python code
| using requests, it's my mother and sister and other ordinary
| users, and so if they increasingly have HTTPS-by-default then
| HSTS stops mattering.
| JoshTriplett wrote:
| I've been running not just HTTPS-by-default but strict HTTPS-
| only for a while now. Firefox, at least, mostly even handles
| things like captive portals correctly. Judging by the rarity of
| encountering anything that has HTTP and doesn't listen on
| HTTPS, I think we're to the point where any non-technical user
| could use an HTTPS-only configuration and correctly treat any
| site that doesn't work with it as broken.
| aargh_aargh wrote:
| 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?
| Ellipsis753 wrote:
| 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 wrote:
| Your second example would also be prevented by just not
| serving on port 80 as the parent comment suggests, no?
| meindnoch wrote:
| >no?
|
| No.
| ycombinatrix wrote:
| No, not really. You can still be MITMed on port 80.
| tetha wrote:
| 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 wrote:
| 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.
| gwbas1c wrote:
| 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 wrote:
| 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.
| ozim wrote:
| 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.
| Arbortheus wrote:
| 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).
| dspillett wrote:
| 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).
| arccy wrote:
| it's a note at the very end, but there are TLDs like .dev where
| all domains under it have HTTPS enforced.
| tialaramex wrote:
| Specifically .dev has HSTS pre-loaded everywhere. But that's
| not the same thing as HTTPS enforced. There are protocols built
| on HTTP which can't do TLS, those also don't obey HSTS (it
| would be pointless) and so they work fine on .dev as do HTTP
| services for non-humans who also needn't obey HSTS and
| presumably already understand the consequences.
| ocdtrekkie wrote:
| HSTS remains a broken antifeature which violates the covenant of
| a browser agent being a browser agent. (A server should never
| have more authority than me on dictating how my agent works.)
|
| Firefox refuses to support the ability to bypass HSTS which
| generally means I'm forced to use a different browser when HSTS
| is getting in the way of me doing my job.
|
| (Thankfully or unfortunately, Chromium-based browsers violate the
| HSTS spec and allow bypass. But there seems to be no appetite to
| actually repair the HSTS spec to permit this.)
| SkyPuncher wrote:
| When does HSTS get in your way?
| ycombinatrix wrote:
| When I'm unable to turn it off.
| winstonwinston wrote:
| > Chromium-based browsers violate the HSTS spec and allow
| bypass.
|
| If you were able to bypass HSTS using google chrome, that
| sounds like a bug.
___________________________________________________________________
(page generated 2025-12-30 23:00 UTC)