On the very first connection from the browser to the website, yes. But the browser saves the HSTS setting (for the time specified by the HSTS header's max-age value) so future connections go straight to HTTPS.
It seems silly that Chromium and Firefox now have separate HSTS lists (though Firefox's was seeded using the Chromium list [1]).
At the moment, these lists appear to be b) tied to specific browsers 2) tied to specific releases of those browsers.
Would it be viable to run some kind of global open registry where any website can be registered for mandatory HSTS? That way, every individual website owner doesn't need to submit a bug to Chromium and Mozilla - the browser just needs to securely connect to the registry and download the latest list. Or maybe DNSSEC can help ...
Maybe work on this is already underway, but I was reading some MLs a few weeks ago and I didn't see any forthcoming solutions ...
I believe that Firefox is still generating its HSTS preload list from Chromium's - a few months ago I got a site added to Chromium's HSTS list and a few weeks later it showed up in Firefox. I couldn't even figure out how to submit directly to Firefox.
I agree that a global registry would be better, but it should probably be updated using the browser's normal update channel, to avoid re-inventing the wheel. (And DNSSEC has way too many issues.) It's true that ties the list to specific releases, but since browsers have good, and frequent, auto-updating, I think that's OK.
Ok, so how about the attacker intercepts the https request with a self-signed cert, modifies the stored HSTS header by issuing a new max-age of 0.25 second, and includes a redirect back to http://?
This just kind of seems unwinnable, a million holes.
Ok, so how about the attacker intercepts the https request with a self-signed cert, modifies the stored HSTS header by issuing a new max-age of 0.25 second, and includes a redirect back to http://?
HSTS disallows the user from overriding the certificate warning and accepting a self-signed cert.
(You just edited your comment, didn't you) Well, that's a good detail then.
Does it in fact reject connections to self-signed certs? Or just disallow you from accepting the broken cert? Because the real goal would just be to get the user onto http:// as quick as possible, and then the untrusted warning is gone.
(You keep editing your comments, replacing old questions with new questions, which makes it rather difficult to reply to you. I suggest making new comments instead.)
Does it in fact reject connections to self-signed certs?
Yes, you don't even need HSTS for this. HSTS just disallows the user from overriding the browser and accepting the self-signed (or otherwise bad) certificate.
But an attacker can certainly intercept HTTPS as well, and if they redirect you quick enough you'll never see the "wrong cert" errors.
No, any sort of HTTPS interception will be detected by the browser (assuming of course that the certificate authority infrastructure has not been compromised). There's no way to redirect "quick enough" to bypass certificate checking.
Of course it is detected, we are not trying to fool the PC. When I visit my personal website with a flawed certificate (for example, once I was missing the Intermediate CA) it loads the site all the same, but the lock icon shows a security verification failure.
What in HSTS protects you from that? Because it seems to me if you can get there, you can get back to http:// before the user notices the verification failure. Unless the browser simply refuses to load the site due to the verification failure, which I only see for "suspected attack sites"
Intercept 443 => Issue insecure page with new HSTS timeout => Redirect to 80 before user notices insecure page warning
But it only loads because you added an exception at some point in the past. On any normal site, it would show you a cert error and wouldn't load the page at all.
For that to work they would have to have access to the browser since the headers would be sent over TLS/SSL after the first connection. If they've got access to the client's machine and browser all bets are off. They could install their own CA and MITM even if the site is using HSTS. Certificate pinning would help solve some of that problem but you might not be able to trust that on a compromised machine anyway.
This whole attack is assuming the attacker is there from the very first packet of the particular login session. Not about inserting a MITM in the middle of an established login session.
The initial connection of an intercepted HTTPS connection would throw a security error, because the attacker would be using the wrong cert, but if you redirect the victim quickly...
You can defeat this particular hole by getting more aggressive about untrusted certificates, but it seems browsers are very reluctant to do that.
Comments
On the very first connection from the browser to the website, yes. But the browser saves the HSTS setting (for the time specified by the HSTS header's max-age value) so future connections go straight to HTTPS.
Chrome and Firefox also ship with a baked-in HSTS preload list containing sites that should always use HTTPS, without depending on the HSTS header: http://src.chromium.org/viewvc/chrome/trunk/src/net/http/tra...
It seems silly that Chromium and Firefox now have separate HSTS lists (though Firefox's was seeded using the Chromium list [1]).
At the moment, these lists appear to be b) tied to specific browsers 2) tied to specific releases of those browsers.
Would it be viable to run some kind of global open registry where any website can be registered for mandatory HSTS? That way, every individual website owner doesn't need to submit a bug to Chromium and Mozilla - the browser just needs to securely connect to the registry and download the latest list. Or maybe DNSSEC can help ...
Maybe work on this is already underway, but I was reading some MLs a few weeks ago and I didn't see any forthcoming solutions ...
1. https://blog.mozilla.org/security/2012/11/01/preloading-hsts...
I believe that Firefox is still generating its HSTS preload list from Chromium's - a few months ago I got a site added to Chromium's HSTS list and a few weeks later it showed up in Firefox. I couldn't even figure out how to submit directly to Firefox.
I agree that a global registry would be better, but it should probably be updated using the browser's normal update channel, to avoid re-inventing the wheel. (And DNSSEC has way too many issues.) It's true that ties the list to specific releases, but since browsers have good, and frequent, auto-updating, I think that's OK.
Every weekend the list from Chrome is used to automatically update Firefox in tree version.
Got it. So not 100% full-proof (not that anything is).
This also means that once you switch to using HSTS, you can't go back.
You could, it will just take 180 days (or whatever you have it set to).
Ok, so how about the attacker intercepts the https request with a self-signed cert, modifies the stored HSTS header by issuing a new max-age of 0.25 second, and includes a redirect back to http://?
This just kind of seems unwinnable, a million holes.
HSTS disallows the user from overriding the certificate warning and accepting a self-signed cert.
(You just edited your comment, didn't you) Well, that's a good detail then.
Does it in fact reject connections to self-signed certs? Or just disallow you from accepting the broken cert? Because the real goal would just be to get the user onto http:// as quick as possible, and then the untrusted warning is gone.
(You keep editing your comments, replacing old questions with new questions, which makes it rather difficult to reply to you. I suggest making new comments instead.)
Yes, you don't even need HSTS for this. HSTS just disallows the user from overriding the browser and accepting the self-signed (or otherwise bad) certificate.
What browser flat-out refuses to connect to a webpage with an invalid SSL cert? Is this a recent development?
Edit: Apparently all of them now, I sure didn't notice that. Not a concern, then
Test site: https://tv.eurosport.com/
No, any sort of HTTPS interception will be detected by the browser (assuming of course that the certificate authority infrastructure has not been compromised). There's no way to redirect "quick enough" to bypass certificate checking.
Of course it is detected, we are not trying to fool the PC. When I visit my personal website with a flawed certificate (for example, once I was missing the Intermediate CA) it loads the site all the same, but the lock icon shows a security verification failure.
What in HSTS protects you from that? Because it seems to me if you can get there, you can get back to http:// before the user notices the verification failure. Unless the browser simply refuses to load the site due to the verification failure, which I only see for "suspected attack sites"
But it only loads because you added an exception at some point in the past. On any normal site, it would show you a cert error and wouldn't load the page at all.
For that to work they would have to have access to the browser since the headers would be sent over TLS/SSL after the first connection. If they've got access to the client's machine and browser all bets are off. They could install their own CA and MITM even if the site is using HSTS. Certificate pinning would help solve some of that problem but you might not be able to trust that on a compromised machine anyway.
This whole attack is assuming the attacker is there from the very first packet of the particular login session. Not about inserting a MITM in the middle of an established login session.
The initial connection of an intercepted HTTPS connection would throw a security error, because the attacker would be using the wrong cert, but if you redirect the victim quickly...
You can defeat this particular hole by getting more aggressive about untrusted certificates, but it seems browsers are very reluctant to do that.
"Quickly" really isn't applicable in this case, though.
If there's no HSTS record for the domain,
- if it's HTTP, the attacker succeeds.
- if it's HTTPS with an invalid cert, the browser will display a warning and not honor any redirects.
- if it's HTTPS with a valid cert, we assume there is no attack (cert misissuance is an attack outside the scope of HSTS).
If there's an HSTS record for the domain,
- if it's HTTP, the browser will automatically rewrite to HTTPS.
- if it's HTTPS with an invalid cert, the browser produces a hard fail that the user can't override (and ignores redirects).
- if it's HTTPS with a valid cert, as above, the browser accepts the cert and we assume it's not an attack.