Hacker News Reader

Comment by jenseng | Hacker News Reader

The author seems to gloss over the importance of browser built-in HSTS lists. If you're just relying on a response header to tell the browser to use HTTPS, aren't you still vulnerable? Isn't that the same fundamental problem with redirecting to HTTPS via Location headers?

In other words, a MITM could downgrade any HTTPS traffic and simply remove that STS header. The browser would be none the wiser.

View on HN

No, that's not how STS works. Once the header is set, a MITM can't simply clear the header; the purpose of STS is to tell the browser to remember that the site is HTTPS-only.

You are, obviously, vulnerable on first contact to a site, in that an attacker can prevent you from ever seeing the STS header. The point of STS is that attackers don't generally get to intercept your first contact with a site.

Adam Langley, by the way, is one of Google's Chrome SSL/TLS/HTTPS people.

If you're in an oppressive country (say Syria), for example, is it a bad assumption that you're always being MITM'd, and unless you leave the country (not likely) EVERY first contact you make is already compromised? It's a tough chicken and egg problem.

I'm really not sure what the point of this debate is. There are countries oppressive enough where I'd be worried that most of the computers in them are backdoored and keylogged. HSTS doesn't have anything to say about that either.

Similarly: a country savvy enough to have a whole regime for ensuring they have custody of all transactions from first contact on probably isn't a country that offers safe access to browser binaries either, which kind of hurts the utility of baked-in SSL restrictions.

The thing which terrifies me is that most of the users in these "screwed" countries are probably using mobile phones connected to a state-owned PTT carrier (or a couple of licensed carriers), rather than laptops or desktops, at least for most organizing. True, a lot of the devices are purchased through the grey market unlocked vs. via the carrier, but it's not hard for a carrier to push OTA evil

If clearing the browser cache/cookies makes the browser forget about STS for each domain, then MITM attacker gets a lot more chances to intercept and attack. I don't have stats on how often average users clear their browsers but it is a fairly common troubleshooting step so most people are aware of it.

If clearing the browser cache/cookies does not make the browser forget about STS for each domain, then we got another way to maintain http://samy.pl/evercookie/

The whole point of tracking cookies is to maintain some identifier. With STS you only get 1 bit, how do you identify them? All users who have visited the site since (now - STS expiration length) look the same.

On the other hand, if the Chinese government finds out you have an HSTS flag for https://www.youversion.com/ or some such...

I should clarify, I was referring to the first visit to the site. So yes, I can see how this greatly reduces the vulnerability, though it doesn't completely remove it.

As an example, a rogue Apple Store employee could insert him self as a MITM between the access point and the internet connection. Anyone testing out a new laptop in the store (or logging in to their bank from a just-activated iphone) would be vulnerable, without the attacker ever having touched any of those devices.

There are a lot of real security issues HSTS doesn't protect against. But for its miniscule cost, it does a very good job of protecting against one specific real threat.

I guess the real lessons there for users is "don't do anything sensitive on a device that's not yours. or on one you just acquired, unless you trust every hop between you and the server". But users generally don't know/care/think about these things :)

The STS header has an expiration date on it.

Let's assume you have it set to 1 year. If user A visits the site in March, receives the header, uses the site for a while.

In May, the site/user's DNS/whatever is hijacked. Users are sent to a dummy site, which does not set the header. The dummy site is over HTTP.

The next day, the user tries to go to the site. Because it is not over HTTPS, the browser refuses to load the page, even though the header is no longer sent.

    strict-transport-security:max-age=2592000; includeSubDomains

It has a maximum age, not an expiration date. If I visit gmail today, that STS header will expire a month from now[1].

If I visit again tomorrow, the browser-cached version of that header will be updated with a new expiration date, and expire a month from tomorrow, not now.

1: http://www.wolframalpha.com/input/?i=2592000%20seconds

edit: I think we're agreeing.

Reply on news.ycombinator.com