4 ms·

I'm interested in what these attacks are and what you think would be better. Especially with HSTS preloading (supported in Chrome, Firefox, IE, and Edge) I don'

by Buge 10y ago

I'm interested in what these attacks are and what you think would be better. Especially with HSTS preloading (supported in Chrome, Firefox, IE, and Edge) I don't see any attacks really.

niftich 10y ago
Potential security considerations identified by the authors of HSTS are manyfold [1]. The most obvious is (14.6) 'Bootstrap MITM Vulnerability' states that since a non-preloaded site's initial contact will be through a non-secure channel, a man-in-the-middle can tamper with the response and never set a HSTS policy, or set an intentionally misconfigured HSTS policy. Preload is designed to mitigate against this, but preloading every single website is... difficult. [1] https://tools.ietf.org/html/rfc6797#section-14 https://tools.ietf.org/html/rfc6797#section-14
- mkj 10y ago
  You can't set a misconfigured policy over http, it needs to be HTTPS with a valid CA.
  - niftich 10y ago
    That's not entirely clear from the spec. Per section 11.3 [1], if HTST policy is enabled with a self-signed cert, then "then secure connections to that site will fail, per the HSTS design". In my reading, it doesn't say that a compliant user-agent must not set HSTS policies for self-signed certs; rather, it says a compliant user-agent will show an un-remediable error upon attempt to visit the website. [1] https://tools.ietf.org/html/rfc6797#section-11.3 https://tools.ietf.org/html/rfc6797#section-11.3
    - icebraining 10y ago
      Regardless of spec, none of the major browsers accept HSTS policies from sites with self-signed certs.
peterwwillis 10y ago
1. Target a Windows user older than Windows 7, or any version of IE older than 11, since HSTS is not supported there (RFC section 14.2) 2. Bootstrap MITM vulnerability (RFC section 14.6) 3. NTP attacks (RFC section 14.7) [1] 4. Send RSTs on all HTTPS traffic. Eventually the user will get fed up with the website not working and try plain HTTP on a different browser/client which doesn't have the HSTS policy cached. 4.1. After the new client connects, force some kind of error or warning on the connection, but still allow it to continue, and use SSL stripping for any initial plaintext connections. HSTS will not be set if any warnings or errors are found on the connection. (RFC section 14.3) 5. Phishing: Send non-secure URLs to your target with instructions that if the connection fails, try the same non-secure link on a different browser. (It may be easier to just register a fake-but-similar-sounding domain and give it a valid cert, and send links to that) 5.1. Phishing with a non-secure root domain cert (RFC section 14.8) 6. Develop a method to determine when a client's policy will expire - or just wait - and wait to attack the moment of the next request, which will [potentially] be in plain HTTP. 7. Invalid configuration, such as forgetting to include the 'includeSubDomains' flag. 8. Internationalized domain names (RFC section 14.10) Pre-loaded HSTS lists are affected with some of the above attacks, and public-key lists are affected eventually because eventually you need to rotate a key. [1] https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security-wp.pdf https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-By... -- These are just the ten identified attacks so far, and they all stem from the design itself, which allows MITM on first connection or policy expiration. If your whole security feature is designed to allow MITM even once, it is guaranteed to happen at least once. This is why it's a well-intentioned bad hack. The solution was - and still is - to design a protocol which will never allow insecure connections. This could be accomplished by forking SPDY or HTTP2.0 and naming the new protocol "SECURE", and passing out URLs like 'secure://google.com/'. This way it would be totally obvious to both the user and the browser that the connection should only ever be made using at least a valid signed cert, and HSTS would never be needed (but public-key pinning would still be needed). Mandatory DNS-based security would improve this further. This almost happened with HTTP/2, but nobody proposed the new protocol name. Terrible missed opportunity.
- icebraining 10y ago
  A 'secure:' scheme sounds good, but I don't see how would it solve (1), (2), (5), (5.1) and (8); the scheme can't protect you if the attackers can switch it out or send the user to a domain they control.
kuschku 10y ago
> Especially with HSTS preloading HSTS preloading is just distorting the market towards the already large sites. A smaller site now will get ads injected by your ISP, but their larger competitor doesn’t. Yet, you obviously can’t add every single private blog to the preloading list. I tried getting my personal blog added, it’s just impossible. So your solution is only good for the already huge websites. What’s with democratizing the internet, giving every single personal blog the same tools as every huge site?
- icebraining 10y ago
  I tried getting my personal blog added, it’s just impossible. Why? https://hstspreload.appspot.com/ https://hstspreload.appspot.com/ didn't work?
  - kuschku 10y ago
    Last I tried was a few years ago when that didn’t exist, nice that it does exist now. I wonder what will happen once the preload lists are several billion pages long?
    - pfg 10y ago
      Hopefully by that time we've reached the point where we can deprecate HTTP without TLS and show appropriate warnings in browsers.
- C4K3 10y ago
  > I tried getting my personal blog added, it’s just impossible. I got my personal blog, which gets less than 100 unique visitors a month, added with no problems at all.
  - kuschku 10y ago
    I wanted to edit, but can’t edit anymore, and couldn’t answer comments due to the comment limit until now, but here it is: Last I tried was a few years ago, when the official stance was "only the top 100 will be added".

by Buge 10y ago

I'm interested in what these attacks are and what you think would be better. Especially with HSTS preloading (supported in Chrome, Firefox, IE, and Edge) I don't see any attacks really.

niftich 10y ago

Potential security considerations identified by the authors of HSTS are manyfold [1]. The most obvious is (14.6) 'Bootstrap MITM Vulnerability' states that since a non-preloaded site's initial contact will be through a non-secure channel, a man-in-the-middle can tamper with the response and never set a HSTS policy, or set an intentionally misconfigured HSTS policy. Preload is designed to mitigate against this, but preloading every single website is... difficult. [1] https://tools.ietf.org/html/rfc6797#section-14 https://tools.ietf.org/html/rfc6797#section-14

mkj 10y ago
You can't set a misconfigured policy over http, it needs to be HTTPS with a valid CA.
- niftich 10y ago
  That's not entirely clear from the spec. Per section 11.3 [1], if HTST policy is enabled with a self-signed cert, then "then secure connections to that site will fail, per the HSTS design". In my reading, it doesn't say that a compliant user-agent must not set HSTS policies for self-signed certs; rather, it says a compliant user-agent will show an un-remediable error upon attempt to visit the website. [1] https://tools.ietf.org/html/rfc6797#section-11.3 https://tools.ietf.org/html/rfc6797#section-11.3
  - icebraining 10y ago
    Regardless of spec, none of the major browsers accept HSTS policies from sites with self-signed certs.

peterwwillis 10y ago

1. Target a Windows user older than Windows 7, or any version of IE older than 11, since HSTS is not supported there (RFC section 14.2) 2. Bootstrap MITM vulnerability (RFC section 14.6) 3. NTP attacks (RFC section 14.7) [1] 4. Send RSTs on all HTTPS traffic. Eventually the user will get fed up with the website not working and try plain HTTP on a different browser/client which doesn't have the HSTS policy cached. 4.1. After the new client connects, force some kind of error or warning on the connection, but still allow it to continue, and use SSL stripping for any initial plaintext connections. HSTS will not be set if any warnings or errors are found on the connection. (RFC section 14.3) 5. Phishing: Send non-secure URLs to your target with instructions that if the connection fails, try the same non-secure link on a different browser. (It may be easier to just register a fake-but-similar-sounding domain and give it a valid cert, and send links to that) 5.1. Phishing with a non-secure root domain cert (RFC section 14.8) 6. Develop a method to determine when a client's policy will expire - or just wait - and wait to attack the moment of the next request, which will [potentially] be in plain HTTP. 7. Invalid configuration, such as forgetting to include the 'includeSubDomains' flag. 8. Internationalized domain names (RFC section 14.10) Pre-loaded HSTS lists are affected with some of the above attacks, and public-key lists are affected eventually because eventually you need to rotate a key. [1] https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security-wp.pdf https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-By... -- These are just the ten identified attacks so far, and they all stem from the design itself, which allows MITM on first connection or policy expiration. If your whole security feature is designed to allow MITM even once, it is guaranteed to happen at least once. This is why it's a well-intentioned bad hack. The solution was - and still is - to design a protocol which will never allow insecure connections. This could be accomplished by forking SPDY or HTTP2.0 and naming the new protocol "SECURE", and passing out URLs like 'secure://google.com/'. This way it would be totally obvious to both the user and the browser that the connection should only ever be made using at least a valid signed cert, and HSTS would never be needed (but public-key pinning would still be needed). Mandatory DNS-based security would improve this further. This almost happened with HTTP/2, but nobody proposed the new protocol name. Terrible missed opportunity.

icebraining 10y ago
A 'secure:' scheme sounds good, but I don't see how would it solve (1), (2), (5), (5.1) and (8); the scheme can't protect you if the attackers can switch it out or send the user to a domain they control.

kuschku 10y ago

> Especially with HSTS preloading HSTS preloading is just distorting the market towards the already large sites. A smaller site now will get ads injected by your ISP, but their larger competitor doesn’t. Yet, you obviously can’t add every single private blog to the preloading list. I tried getting my personal blog added, it’s just impossible. So your solution is only good for the already huge websites. What’s with democratizing the internet, giving every single personal blog the same tools as every huge site?

icebraining 10y ago
I tried getting my personal blog added, it’s just impossible. Why? https://hstspreload.appspot.com/ https://hstspreload.appspot.com/ didn't work?
- kuschku 10y ago
  Last I tried was a few years ago when that didn’t exist, nice that it does exist now. I wonder what will happen once the preload lists are several billion pages long?
  - pfg 10y ago
    Hopefully by that time we've reached the point where we can deprecate HTTP without TLS and show appropriate warnings in browsers.
C4K3 10y ago
> I tried getting my personal blog added, it’s just impossible. I got my personal blog, which gets less than 100 unique visitors a month, added with no problems at all.
- kuschku 10y ago
  I wanted to edit, but can’t edit anymore, and couldn’t answer comments due to the comment limit until now, but here it is: Last I tried was a few years ago, when the official stance was "only the top 100 will be added".