Comment by pmoriarty | Hacker News Reader

Comment by pmoriarty | Hacker News Reader

"if you just typed in the url (shop.bkk.hu), the site just wouldn't appear. At first I thought they've taken it offline, but it turns out that they just didn't set up the http -> https redirection. And it was left like that for days. If you just heard about it, you couldn't use it. You had to click a link (normal users won't figure out to put an https in front of the host name, even I didn't think of it)."

I'd really like to know which of these is the better solution.

It seems to me that if people go to the http address, they could be redirected to an attacker's address with a simple MITM attack. So there's an argument to be made for not using http at all, even for a legitimate redirect, because it can be so easily MITM'ed.

On the other hand, if the http address is left unused, then people who try it anyway and it fails will be confused. For this solution to work, it seems the users have to be educated to always and only use the https address.

For these reasons, the whole separate http/https scheme seems broken by design.

What's the consensus from the security community as to the right setup here? Am I missing something, or is there a better way?

Not having an http site doesn't help in a MITM scenario as the attacker will happily serve up an http site even if you don't.

The only solution is to always go for the HTTPS resource disregarding any suggestion. On browsers a strict configuration of Smart HTTPS [0] covers that, for everything else I think the best solution would be to intercept all HTTP traffic, request the HTTPS counterpart (and decide if falling back on failure is acceptable instead of just dropping the connection), then serving locally the decrypted response. Worse than properly requesting the right one from the start but harder enough to exploit.

[0] https://mybrowseraddon.com/smart-https.html

It's true that it doesn't help once the user has been MITM'ed.

But before that happens, if the user always goes to the http address and it works for them (whether by legitimate redirect or by the legitimate site simply supporting http) it lulls them in to a false sense of security, and a belief that going to the http address is ok.

So the idea behind having the http address be broken from the start is to make the users see that the address they're trying is broken, and therefore the wrong one for them to use. Hopefully at that point they'll investigate why (perhaps complaining or talking to their sysadmin, if they have one), and be straightened out by someone providing the https link to them (or the more tech-savvy users like the OP figuring it out for themselves).

HSTS helps for this.

See https://hstspreload.org

Ok, so that works for Chrome, but every other application is still going to be subject to an MITM attack if their users try to connect via http?

As long as the other application is Firefox, Safari, IE11/Edge, or Opera, then it probably has a HSTS preload list that is at least in part generated from the Chrome one.

Firefox have some scripts which go through and check to make sure everything still on the Chrome list is still announcing the preload headers, and will autoremove if that isn't that case, IIRC. I wouldn't be too shocked if Apple/Microsoft were doing something similar.

"As long as the other application is Firefox, Safari, IE11/Edge, or Opera, then it probably has a HSTS preload list that is at least in part generated from the Chrome one."

Is there any documentation for these browsers that officially say exactly what they're doing and how their preload lists are generated?

Here's a firefox one

https://wiki.mozilla.org/SecurityEngineering/HTTP_Strict_Tra...

Reply on news.ycombinator.com