Re: [TLS] Broken browser behaviour with SCADA TLS

Peter Gutmann <> Thu, 05 July 2018 02:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA3AB130D7A for <>; Wed, 4 Jul 2018 19:32:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IxFK_KiHaebL for <>; Wed, 4 Jul 2018 19:32:16 -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 81ED6130E1D for <>; Wed, 4 Jul 2018 19:32:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1530757935; x=1562293935; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VyurFvnrqi3fX5nj6w2aDe0NwoAFij0NTuyMc/l9NgU=; b=UVR7+RsKlU67AdUcObsKSiivNiolYWDYkRhcJ8Q6gnuaP6bgg8qxgY1r g9t54vIAo/sNgZ1CB0XBrvJDTBipr3D5IPYZbkjISPWiHNRlhG6lOCg+B IClOn3nJ4IPRtsZy3BFhPCDy28z8suRGEjIf5Uj50ihbxcvJVQzX+85w6 HX5vgcSvRe48FCSuUBXanM+o+m9r3/PnzRFD4za49JwRBZ73wRr5scv8+ sQDF8I2/Op0YwAbVyrRY6HjEYGd4qEVo1XpZ3lCk1CKy9TPCM7APqoQ31 aeR17vF/ijbI1+OC+jTrx7I0XNTwE0dOfwaRNOT1hRVHDBfDlrMubvbbU g==;
X-IronPort-AV: E=Sophos;i="5.51,310,1526299200"; d="scan'208";a="19685623"
X-Ironport-Source: - Outgoing - Outgoing
Received: from (HELO ([]) by with ESMTP/TLS/AES256-SHA; 05 Jul 2018 14:32:09 +1200
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 5 Jul 2018 14:32:08 +1200
Received: from ([fe80::ccab:7bf5:3d4a:aed8]) by ([fe80::ccab:7bf5:3d4a:aed8%14]) with mapi id 15.00.1263.000; Thu, 5 Jul 2018 14:32:08 +1200
From: Peter Gutmann <>
To: David Benjamin <>, Nikos Mavrogiannopoulos <>
CC: Ilari Liusvaara <>, "<>" <>
Thread-Topic: [TLS] Broken browser behaviour with SCADA TLS
Date: Thu, 5 Jul 2018 02:32:08 +0000
Message-ID: <>
References: <> <> <20180704074101.GA19789@LK-Perkele-VII> <> <20180704081519.GA20000@LK-Perkele-VII> <>, <>
In-Reply-To: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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: Thu, 05 Jul 2018 02:32:19 -0000

David Benjamin <>​ writes:

>The bad feedback was not even at a 2048-bit minimum, but a mere 1024-bit
>minimum. (Chrome enabled far more DHE ciphers than others, so we encountered
>a lot of this.) 2048-bit was completely hopeless. At the time of removal, 95%
>of DHE negotiations made by Chrome used a 1024-bit minimum.

How does Google, rather than the people running the systems being connected
to, know that 1024-bit DH isn't secure enough for a given environment?  The
majority of this stuff is running on isolated, private networks or inside VPN
tunnels for which pretty much anything, including 512-bit keys, are fine.

It's also somewhat disturbing that Chrome now walks straight past a perfectly
good PFS DHE suite and instead goes to a problematic pure-RSA one instead.

>You should instruct these folks to configure ECDHE+RSA ciphers if they have
>RSA keys. 

The devices don't do ECDHE, and they probably never will (at least until the
next upgrade cycle, which could take a decade or more), so there's nothing to

>rfc7919, did not fix the problem. This was pointed out here, but never
>incorporated to the document:

Yep.  The issues were pointed out by several people before it was published,
but got published anyway... with the result being that a number of
implementations chose not to support it because of the problems that it

>Particularly in the second scenario, it seems they're already implemented,
>just the server was incorrectly configured to use the wrong ones.

That was in my testing, not using a PLC control centre or similar, in other
words the actual devices being used in the field.  Doing that would have
required a firmware reload for each test, which is way too painful to think
about.  For "server incorrectly configured", see above, they were offering all
the suites the firmware and hardware supported.