3 ms·

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

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:// http://? This just kind of seems unwinnable, a million holes.

agwa 13y ago
> 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:// http://? HSTS disallows the user from overriding the certificate warning and accepting a self-signed cert.
- sliverstorm 13y ago
  (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:// http:// as quick as possible, and then the untrusted warning is gone.
  - agwa 13y ago
    > 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.
    - sliverstorm 13y ago
      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:// 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
      - azdle 13y ago
        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.
  - agwa 13y ago
    (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.
    - sliverstorm 13y ago
      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/ https://tv.eurosport.com/
simcop2387 13y ago
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.
- sliverstorm 13y ago
  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.
  - schoen 13y ago
    "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.

agwa 13y ago

> 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:// http://? HSTS disallows the user from overriding the certificate warning and accepting a self-signed cert.

sliverstorm 13y ago
(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:// http:// as quick as possible, and then the untrusted warning is gone.
- agwa 13y ago
  > 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.
  - sliverstorm 13y ago
    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:// 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
    - azdle 13y ago
      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.
- agwa 13y ago
  (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.
  - sliverstorm 13y ago
    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/ https://tv.eurosport.com/

simcop2387 13y ago

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.

sliverstorm 13y ago
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.
- schoen 13y ago
  "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.