Martin Rex <m...@sap.com> writes: >I would expect that someone who cares about backwards compatibility would >test stuff at least once before shipping.
It's not just their TLS code that does things like this. The Server 2003 SCEP implementation, when sent a standard SCEP GetCACaps message, would immediately drop the connection (which at least let you know what server you were talking to, so it was a sort-of GetCACaps at least). The Server 2012 SCEP implementation will respond to a PKCS #1-wrapped (as per the spec) AES- encrypted SCEP client request with an OAEP-wrapped (completely incorrect) single-DES-encrypted response. I cannot even begin to imagine what sort of coding would produce that level of breakage. This must have been tested on exactly zero implementations before it shipped. >Windows 2008R2 and later looks like entirely untested to me or maybe "tested >only with MSIE and only in default config" For SCADA stuff it's only the client side that matters (browsers being used to admin devices), so I haven't looked at server-side breakage that much. Even then, note the comments in my first message about the bizarro fallback dance + eventual fail to connect that IE goes through. In any case thanks for posting that list, it's good to have for reference. I suspect at least some of that behaviour may be due to the destructive interaction of too many backwards-compatibility hacks... Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls