
Microsoft TLS 1.2 downgrade bug and how it was fixed - jgrahamc
https://blog.cloudflare.com/microsoft-tls-downgrade-schannel-bug/
======
wbond
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.

~~~
ploxiln
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
Yes, the TLS 1.0 fallback (IE skips 1.1) was what hid the problem in this
case.

------
simonw
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
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.

------
prdonahue
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..

