Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote: > > (I have no idea about the prevalence of IE vs. others, but since it's the > default browser for Windows I assume this will be the easiest/recommended path > fowards, and until Windows 10 MS had a long history of being excruciatingly > careful about backwards compatibility so it seems the safest bet).
The last time that I've seen a Microsoft Windows TLS implementation show a reasonble level of interoperability was Windows2003sp2 with Hotfix 948963 installed. Windows 2008R2 has sever interop problems with TLSv1.2, and goofed the RSA premaster secret version check. https://www.ietf.org/mail-archive/web/tls/current/msg08139.html Windows2012R2 made things worse, same TLSv1.2 interop failures, plus default lack of backwards compatibility to non-SNI clients. I was surprised when I just recently saw responses from Windows 2016 Microsoft IIS/10.0 = presumably Windows 2016 Microsoft IIS/8.5 = Windows 2012R2 Microsoft IIS/7.5 = Windows 2008R2 While 2016 seems to have fixed two annoying TLSv1.2 interop failures that affect 2008R2 and 2012R2 (about the TLSv1.2 signature_algorithms extension), Win2016 also newly added two _new_ handshake failures (compared to 2008R2) Comparing Win2016 behaviour for SSLv2Hello vs. extension-less SSLv3 Hello the new behaviour is just crazy: the server requires TLS extension SNI for SSLv3 ClientHellos with client_version=(3,1) and (3,2), but *NOT* for client_version=(3,3) and *NOT* for SSLv2Hellos (any version)! I would expect that someone who cares about backwards compatibility would test stuff at least once before shipping. Windows 2008R2 and later looks like entirely untested to me or maybe "tested only with MSIE and only in default config" -- which is equivalent to "untested" on my scorecard. Windows 2008R2 in default config had TLSv1.2 disabled, and no one seem to have thought of testing with a sha256WithRsaEncryption signed server certificate. -Martin All cells marked with ** are SChannel Bugs. 2003 2008R2 2012R2 2016 -------------------------------------------------------------------- SSLv2Hello offering (3,1) TLSv1.0 TLSv1.0 **FAIL TLSv1.0 SSLv2Hello offering (3,2) TLSv1.0 TLSV1.1 **FAIL TLSv1.1 SSLv2Hello offering (3,3) TLSv1.0 **TLSv1.1 **FAIL **TLSv1.1 ClientHello (no extensions) TLSv1.0 TLSv1.0 **FAIL **FAIL client_version=(3,1) ClientHello (SNI) TLSv1.0 TLSv1.0 TLSv1.0 TLSv1.0 client_version=(3,1) ClientHello (no extensions) TLSv1.0 TLSv1.1 **FAIL **FAIL client_version=(3,2) ClientHello (SNI) TLSv1.0 TLSv1.1 TLSv1.1 TLSv1.1 client_version=(3,2) ClientHello (no extensions) TLSv1.0 **FAIL **FAIL TLSv1.2 client_version(3,3) ClientHello (SNI) TLSv1.0 **FAIL **FAIL TLSv1.2 client_version(3,3) ClientHello (SNI+sig_algs) client_version(3,3) TLSv1.0 TLSv1.2 TLSv1.2 TLSv1.2 The strange SChannel behaviour for SSLv2Hello offering (3,3) affects MSIE 11 Win 7/2008R2 (and probably Win8/8.1/2012/2012R2 as well). When "SSL Version 2" is enabled in "Internet Options" together with TLSv1.2 then interop with an TLSv1.2-enabled Microsoft IIS (SChannel) is still possible, because of the server-side bug to negotiate only TLSv1.1. But when MSIE offers TLSv1.2 in SSLv2Hello to a server with a correct TLS implementation, and that server responds with protocol version TLSv1.2, then MSIE chokes and dies. https://support.microsoft.com/en-us/kb/2851628 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
