Re: [TLS] Broken browser behaviour with SCADA TLS

[Peter Gutmann <[e-mail]>]

Martin Rex <[e-mail]> 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.