Live data from Hacker News

Living with HTTPS

imperialviolet.org

11–20 of 132 posts

Re: Living with HTTPS

#11
post #7
post #5

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.

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…

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.

Re: Living with HTTPS

#12
post #11
post #7

Earlier quoted context omitted.

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…

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 vulnerabl…

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.

Re: Living with HTTPS

#13
post #11
post #7

Earlier quoted context omitted.

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…

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 vulnerabl…

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 :)

Re: Living with HTTPS

#14
post #7

Earlier quoted context omitted.

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…

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.

Re: Living with HTTPS

#15
Somewhat related question: It's fairly common for sites to have static files (images/css) served on a different (sub)domain. What are you supposed to do when the html content is being served on HTTPS? Should the static files be on HTTPS as well? If so, wouldn't it need a different certificate? Certificates are only valid for a single domain, after all.

Re: Living with HTTPS

#16
This was by a wide margin my favorite talk at HOPE this year.

(and a great advertisement for using Chrome in secure settings where you need a web browser)

The irony of Google being one of the main http-only JS resources for a long time was kind of amusing, though.

Re: Living with HTTPS

#17
post #15

Somewhat related question: It's fairly common for sites to have static files (images/css) served on a different (sub)domain. What are you supposed to do when the html content is being served on HTTPS? Should the static files be on HTTPS as well? If so, wouldn't it need a different certificate? Certificates are only valid for a single domain, after all.

You can get SSL certs that are valid for wild card subdomains, e.g. *.example.com

Re: Living with HTTPS

#18
post #15

Somewhat related question: It's fairly common for sites to have static files (images/css) served on a different (sub)domain. What are you supposed to do when the html content is being served on HTTPS? Should the static files be on HTTPS as well? If so, wouldn't it need a different certificate? Certificates are only valid for a single domain, after all.

Wildcard certificates.

Re: Living with HTTPS

#19
post #17
post #15

Somewhat related question: It's fairly common for sites to have static files (images/css) served on a different (sub)domain. What are you supposed to do when the html content is being served on HTTPS? Should the static files be on HTTPS as well? If so, wouldn't it need a different certificate? Certificates are only valid for a single domain, after all.

You can get SSL certs that are valid for wild card subdomains, e.g. *.example.com

Ah, I wasn't aware of that. Thanks!

Re: Living with HTTPS

#20
post #14

Earlier quoted context omitted.

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…

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
Post reply on HN