Hacker News Reader

Comment by frik | Hacker News Reader

I test with HTTP, locally.

This forcing of opinionated things goes on my nerves. How about develop the browser, and let the mass decide what they use. Amazon was 100% HTTP for 20 years (except the single login page) - it worked very well.

View on HN

> This forcing of opinionated things goes on my nerves. How about develop the browser, and let the mass decide what they use.

It's Google's browser forcing one of Google's own gTLDs to HTTPS. There is no masses involved. Anything else on the HSTS preload list is there at the request of the domain or gTLD owners.

> Amazon was 100% HTTP for 20 years (except the single login page) - it worked very well.

Sure it did! It also allowed any interested party to observe all your interactions with Amazon. What worked 20 years ago doesn't necessarily work today. Standards evolve, new attack vectors emerge, and people's needs for privacy or what they expect to be private changes.

It's funny because people complain all the time about how strict security policies are....right up until something gets hacked and then they moan about how the organisations should have done more to protect their accounts.

I'm in the former group but not the latter. I would gladly have some insecurity because it's an indication that we have not become a completely authoritarian society (yet). Bad things happen, that's just how life is and should continue to be; and trying to stop them all will result in something very dystopian.

Online security has nothing to do with dystopia. Running a site over HTTPS works completely transparently to the visitor. Yes there is a little extra pain for the sysadmin setting up the service but that's what they are paid for (and I say this as a systems administrator).

Plus this isn't even the governments intervention, this is browser vendors raising the bar for online security.

HTTP can work if your "local" means strictly "on localhost domain". These days local can also mean that you are running a VM and accessing something that's running there (docker-machine for example). In that case you wouldn't be able to use localhost very trivially (you can do port forwarding, but that's pretty annoying). So you then need to access non-localhost domain for local stuff and browsers don't like this.

https://sites.google.com/a/chromium.org/dev/Home/chromium-se...

Ditto.

I use .local for, well, my local network and I find that Chrome can't find them half the time (telling me that the server can't be found or that I don't have internet connection). Safari, Firefox and even command line tools find them without skipping a beat while Chrome insists that I'm offline.

I think the culprit is the internal DNS cache. If, for whatever reason it can't find the server once, then it gets stored in the cache as unreachable and needs a cache flush to fix. To add insult to injury, in previous versions of Chrome you could disable the internal DNS system, but apparently not anymore.

Same here. Time to check out firefox :)

The HSTS preload list is global, and is used by what you would recognize to be all major browsers.

This is a good thing, of course. Security should be global, not dependent on what browser you happen to use.

Mozilla uses Chrome's HSTS preload list. (Microsoft too.)

I've never quite understood the preload list. Is its only job to save the initial 301 redirect from http > https on first load?

Also, wouldn't bundling (tens of) thousands of domains start to add up, and slow down first page load for regular browser use?

I'm sure I must be missing something, because this doesn't seem very logical to me.

In a way yes, it's trying to avoid the initial redirect. But not in order to save you from the potential latency of the initial redirect:

> These sites do not depend on the issuing of the HSTS response header to enforce the policy, instead the browser is aleady aware that the host requires the use of SSL/TLS before any connection or communication even takes place. This removes the opportunity an attacker has to intercept and tamper with redirects that take place over HTTP.

Read this: https://scotthelme.co.uk/hsts-preloading/

> Also, wouldn't bundling (tens of) thousands of domains start to add up, and slow down first page load for regular browser use?

Why would it? Checking in a data structure if the domain the user requested should be loaded over HTTPS can be done in a perfectly efficient way. A hash table would give you O(1) lookup times on average and there's other things you can use to mitigate the worst case lookup of O(n).

Good answer, thanks.

I was hoping the article would cover the scaling aspect a bit more. I guess it's just meant to be a mid-step towards browsers defaulting to HTTPS at some unknown point in the future.

The maintainer of the HSTS preload list wrote a detailed report on the current state of HSTS preloading last year, covering the list size aspect[1].

[1]: https://docs.google.com/document/d/1LqpwT2aAekrWPtLui5GYdHSG...

> Is its only job to save the initial 301 redirect from http > https on first load?

If there's an attacker between you and the website, you will never see the 301 redirect. The preload list was designed for that kind of scenario.

Thanks for giving that hint!

Reply on news.ycombinator.com