Re: [TLS] Broken browser behaviour with SCADA TLS (Martin Rex) Sat, 07 July 2018 00:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8F985130E54 for <>; Fri, 6 Jul 2018 17:30:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MJOKtBsVhxEO for <>; Fri, 6 Jul 2018 17:30:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 14F1B130E13 for <>; Fri, 6 Jul 2018 17:30:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 41Msv34P20zyPH; Sat, 7 Jul 2018 02:30:23 +0200 (CEST)
X-purgate-ID: 152705::1530923423-000007FB-22CCF857/0/0
X-purgate-size: 3690
X-purgate: clean
X-purgate: This mail is considered clean (visit for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R)
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ( []) by (Postfix) with ESMTP id 41Msv20pl2zGqwh; Sat, 7 Jul 2018 02:30:22 +0200 (CEST)
Received: by (Postfix, from userid 10159) id 09C72409B; Sat, 7 Jul 2018 02:30:22 +0200 (CEST)
In-Reply-To: <>
References: <> <> <> <> <> <>
To: Peter Gutmann <>
Date: Sat, 7 Jul 2018 02:30:21 +0200 (CEST)
CC: Kurt Roeckx <>, Hubert Kario <>, "" <>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
From: (Martin Rex)
Archived-At: <>
Subject: Re: [TLS] Broken browser behaviour with SCADA TLS
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 07 Jul 2018 00:30:29 -0000

Peter Gutmann <> 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.

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.


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

ClientHello (SNI)             TLSv1.0   TLSv1.0   TLSv1.0   TLSv1.0

ClientHello (no extensions)   TLSv1.0   TLSv1.1   **FAIL    **FAIL

ClientHello (SNI)             TLSv1.0   TLSv1.1   TLSv1.1   TLSv1.1

ClientHello (no extensions)   TLSv1.0   **FAIL    **FAIL    TLSv1.2

ClientHello (SNI)             TLSv1.0   **FAIL    **FAIL    TLSv1.2

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.