5 ms·

Microsoft TLS 1.2 downgrade bug and how it was fixed

76 points by jgrahamc 11y ago

wbond 11y ago
Having worked with SChannel to build a Python wrapper, there are a number of little bugs that require falling back to TLS 1.1 or retrying the connection. For instance, if a trust root uses an MD5 signature, TLS 1.2 can't be used. Also, sometimes the dhparams for a key exchange will be encoded in 1016 bits instead of 1024 (the server omits a leading zero byte) and SChannel aborts with a cryptic error about buffers being too small. At least Microsoft generally does a better job with their crypto docs than Apple does.
- toast0 11y ago
  FYI, that dhparams bug happens with 2048/2040 as well, and it's fixed in windows 10.
  - wbond 11y ago
    Thanks for letting me know about the fix in 10. Too bad it didn't make it into 8/2012.
    - prdonahue 11y ago
      It's very rare that they patch SChannel outside of just shipping newer versions in subsequent Windows releases. Too many things that can go wrong (see the prior update where they broke something and had to pull back/re-patch).
      - yuhong 11y ago
        I was surprised when this prior update went with DHE_RSA instead of ECDHE_RSA in the first place.
- ploxiln 11y ago
  That makes it sound like the "bug" (lack of support for updating TLS session keys) was known for a long time, and the original "fix" was the client admitting it didn't really fully do TLS 1.2, which based on your experience seems to be a typical "fix" in SChannel. (or, I'll admit, it's more likely the fallback after a "failed negotiation" was a "robustness" behavior that essentially hid problems)
  - yuhong 11y ago
    Yes, the TLS 1.0 fallback (IE skips 1.1) was what hid the problem in this case.
prdonahue 11y ago
Does anyone else know who rotates their session ticket keys? I'm aware of Twitter (jsha's post here: https://blog.twitter.com/2013/forward-secrecy-at-twitter-0 https://blog.twitter.com/2013/forward-secrecy-at-twitter-0), but not really any others..
simonw 11y ago
Absolutely fascinating post, thank you very much for sharing. Does this mean that users of Microsoft operating systems who have not yet applied to the patch will be unable to connect to CloudFlare fronted websites?
- prdonahue 11y ago
  Depends on which Microsoft OS and user agent. If, e.g., you're using an unpatched Windows 8.1 with IE11, you'll still be able to connect initially but will get disconnected the first time the key is rotated (max of 1 hour). Upon disconnection, IE11 will downgrade from TLS 1.2 to 1.0 and try again with a new session, so the user probably won't notice anything unless they're looking for it. That being said, many sites are starting to deprecate TLS 1.0, so this could become more of a problem for patch laggards. If, instead, you're using a .NET client that doesn't try/catch the exception, your program will most likely crash. For customers like this with had a high dependency on Microsoft clients, we simply disabled the issuance of session tickets (just for their site) until the fix was made public. Basically, SChannel freaks out when it sees a new session ticket presented during the abbreviated handshake (it handles it fine during the full handshake). Without seeing their code, it appears that only portions of RFC 5077 were implemented. Btw, most sites don't ever bother to ever rotate their session ticket keys outside of httpd process restarts, so this is why it wasn't discovered for so long.

76 points by jgrahamc 11y ago

wbond 11y ago

Having worked with SChannel to build a Python wrapper, there are a number of little bugs that require falling back to TLS 1.1 or retrying the connection. For instance, if a trust root uses an MD5 signature, TLS 1.2 can't be used. Also, sometimes the dhparams for a key exchange will be encoded in 1016 bits instead of 1024 (the server omits a leading zero byte) and SChannel aborts with a cryptic error about buffers being too small. At least Microsoft generally does a better job with their crypto docs than Apple does.

toast0 11y ago
FYI, that dhparams bug happens with 2048/2040 as well, and it's fixed in windows 10.
- wbond 11y ago
  Thanks for letting me know about the fix in 10. Too bad it didn't make it into 8/2012.
  - prdonahue 11y ago
    It's very rare that they patch SChannel outside of just shipping newer versions in subsequent Windows releases. Too many things that can go wrong (see the prior update where they broke something and had to pull back/re-patch).
    - yuhong 11y ago
      I was surprised when this prior update went with DHE_RSA instead of ECDHE_RSA in the first place.
ploxiln 11y ago
That makes it sound like the "bug" (lack of support for updating TLS session keys) was known for a long time, and the original "fix" was the client admitting it didn't really fully do TLS 1.2, which based on your experience seems to be a typical "fix" in SChannel. (or, I'll admit, it's more likely the fallback after a "failed negotiation" was a "robustness" behavior that essentially hid problems)
- yuhong 11y ago
  Yes, the TLS 1.0 fallback (IE skips 1.1) was what hid the problem in this case.

prdonahue 11y ago

Does anyone else know who rotates their session ticket keys? I'm aware of Twitter (jsha's post here: https://blog.twitter.com/2013/forward-secrecy-at-twitter-0 https://blog.twitter.com/2013/forward-secrecy-at-twitter-0), but not really any others..

simonw 11y ago

Absolutely fascinating post, thank you very much for sharing. Does this mean that users of Microsoft operating systems who have not yet applied to the patch will be unable to connect to CloudFlare fronted websites?

prdonahue 11y ago
Depends on which Microsoft OS and user agent. If, e.g., you're using an unpatched Windows 8.1 with IE11, you'll still be able to connect initially but will get disconnected the first time the key is rotated (max of 1 hour). Upon disconnection, IE11 will downgrade from TLS 1.2 to 1.0 and try again with a new session, so the user probably won't notice anything unless they're looking for it. That being said, many sites are starting to deprecate TLS 1.0, so this could become more of a problem for patch laggards. If, instead, you're using a .NET client that doesn't try/catch the exception, your program will most likely crash. For customers like this with had a high dependency on Microsoft clients, we simply disabled the issuance of session tickets (just for their site) until the fix was made public. Basically, SChannel freaks out when it sees a new session ticket presented during the abbreviated handshake (it handles it fine during the full handshake). Without seeing their code, it appears that only portions of RFC 5077 were implemented. Btw, most sites don't ever bother to ever rotate their session ticket keys outside of httpd process restarts, so this is why it wasn't discovered for so long.