Hacker News Reader

Comment by necovek | Hacker News Reader

My biggest gripe with the current de facto recommended approach (even mandated in HSTS) is that you need to redirect to https from untrusted http.

So you are being forced to either not serve http, or to condition users to trust MITM-able redirect. How many people will notice a typoed redirect to an https page with a good certificate?

The solution is simple: browsers should default to https, and fall back to http if unavailable. Sure, some sites have broken https endpoints, but browsers have enforced crazier shit recently.

View on HN

That's what HSTS is for - you set a HSTS policy, and the browser will remember this site for a certain time you can set (usually 1-2 years).

And going further, you can enable HSTS preloading, meaning the next release of browsers is going to hardcode your website as always and only ever going to be used with HTTPS.

See for example my domain https://hstspreload.org/?domain=kuschku.de, which is currently in the preload lists of all major browsers including Chrome, Firefox, Edge and even Internet Explorer.

I also deploy the same for mail submission with forced STS, and several other protocols.

Right, so HSTS will protect a visitor who has visited your web site at most max-age ago using that particular browser and device.

Or, as I stated, for preload, you have to either not have HTTP at all, or have a redirect to HTTPS: it should be clear from my above post why I think a redirect is a bad idea. I also dislike turning off HTTP for those that don't have any other option.

To me it seems that browsers just switching to https-by-default and http-as-fallback is a much simpler, better, backwards-compatible change that should just work. What am I missing and why do you feel HSTS is a good idea compared to that?

Because some websites serve something different on 443 and 80, and you won’t get the right result by visiting 443.

The preload list allows you to specifically say that for your own website clients should always use HTTPS, which is a good solution, as it means no one is ever going to visit kuschku.de on port 80, except for curl and dev tools, for which the redirect is useful.

I disagree with the claim that it's better for a web site to implement HSTS than to fix whatever they are serving on 443.

But to each their own.

It’s possible for me, today, to implement HSTS, and have my site served securely everywhere, today.

Browsers can’t set 443 as default, because other websites are broken, other websites I can’t fix and the browsers can’t fix either.

We have differing views of "everywhere, today": you acknowledged yourself there are cases where it won't happen, it's just how much we think that's important where we differ. That's ok, I appreciate your point and thanks for spending the time to explain.

As for what browsers can or cannot do, they also can't introduce DNS-over-http, introduce stricter cookie policies breaking a bunch of web sites, or reduce effectiveness of ad-blockers, drop flash, or... Sure, defaulting to https is too high a bar (not expressing an opinion on any of those — eg. good riddance to Flash :) — but browsers can and have done stuff that's just as bad, forcing web site creators to adapt their web sites).

Annoyingly, if you want to get a let's encrypt cert you have to serve http. Back when I was manually purchasing & installing certs I didn't even listen on 80 for several services.

(Exception being if you use the dns challenge)

>(Exception being if you use the dns challenge)

Exactly. DNS challenges don't suffer from this issue.

Reply on news.ycombinator.com