From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "mrex@sap.com" <mrex@sap.com>
CC: Kurt Roeckx <kurt@roeckx.be>, Hubert Kario <hkario@redhat.com>,
 "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Broken browser behaviour with SCADA TLS
Thread-Index: AQHUE2JmEGgXYKCP9EqF19k6tdX1YKR92r8AgADQEJ///2EpAIAAJ+eAgAGuV0eAAkE7gIAA2umH
Date: Sat, 7 Jul 2018 01:34:52 +0000
Message-ID: <1530927270479.40817@cs.auckland.ac.nz>
References: <1530687136897.97792@cs.auckland.ac.nz>
 <CABkgnnXsM2_PsL_YsuNEh6eDyp-R2d2JRm6OmGFh9nRAV5Lukg@mail.gmail.com>
 <1530690320155.99154@cs.auckland.ac.nz>
 <1673271.m6b9jqBoj9@pintsize.usersys.redhat.com>
 <20180704122407.GA10998@roeckx.be>
 <1530756330644.68072@cs.auckland.ac.nz>,
 <20180707003022.09C72409B@ld9781.wdf.sap.corp>
In-Reply-To: <20180707003022.09C72409B@ld9781.wdf.sap.corp>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/GbCK1xNf_plABGelk6wUZU_hKKw>
Subject: Re: [TLS] Broken browser behaviour with SCADA TLS
Precedence: list

Martin Rex <mrex@sap.com> writes:=0A=
=0A=
>I would expect that someone who cares about backwards compatibility would=
=0A=
>test stuff at least once before shipping.=0A=
=0A=
It's not just their TLS code that does things like this.  The Server 2003 S=
CEP=0A=
implementation, when sent a standard SCEP GetCACaps message, would immediat=
ely=0A=
drop the connection (which at least let you know what server you were talki=
ng=0A=
to, so it was a sort-of GetCACaps at least).  The Server 2012 SCEP=0A=
implementation will respond to a PKCS #1-wrapped (as per the spec) AES-=0A=
encrypted SCEP client request with an OAEP-wrapped (completely incorrect)=
=0A=
single-DES-encrypted response.=0A=
=0A=
I cannot even begin to imagine what sort of coding would produce that level=
 of=0A=
breakage.  This must have been tested on exactly zero implementations befor=
e=0A=
it shipped.=0A=
=0A=
>Windows 2008R2 and later looks like entirely untested to me or maybe "test=
ed=0A=
>only with MSIE and only in default config"=0A=
=0A=
For SCADA stuff it's only the client side that matters (browsers being used=
 to=0A=
admin devices), so I haven't looked at server-side breakage that much.  Eve=
n=0A=
then, note the comments in my first message about the bizarro fallback danc=
e +=0A=
eventual fail to connect that IE goes through.=0A=
=0A=
In any case thanks for posting that list, it's good to have for reference. =
 I=0A=
suspect at least some of that behaviour may be due to the destructive=0A=
interaction of too many backwards-compatibility hacks...=0A=
=0A=
Peter.=0A=