Re: [TLS] Broken browser behaviour with SCADA TLS

Peter Gutmann <pgut001@cs.auckland.ac.nz> Thu, 05 July 2018 02:32 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA3AB130D7A for <tls@ietfa.amsl.com>; Wed, 4 Jul 2018 19:32:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxFK_KiHaebL for <tls@ietfa.amsl.com>; Wed, 4 Jul 2018 19:32:16 -0700 (PDT)
Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81ED6130E1D for <tls@ietf.org>; Wed, 4 Jul 2018 19:32:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; 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-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.3.4 - Outgoing - Outgoing
Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-c.UoA.auckland.ac.nz) ([10.6.3.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 05 Jul 2018 14:32:09 +1200
Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-tdc-c.UoA.auckland.ac.nz (10.6.3.24) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 5 Jul 2018 14:32:08 +1200
Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::ccab:7bf5:3d4a:aed8]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::ccab:7bf5:3d4a:aed8%14]) with mapi id 15.00.1263.000; Thu, 5 Jul 2018 14:32:08 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: David Benjamin <davidben@chromium.org>, Nikos Mavrogiannopoulos <nmav@redhat.com>
CC: Ilari Liusvaara <ilariliusvaara@welho.com>, "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] Broken browser behaviour with SCADA TLS
Thread-Index: AQHUE2JmEGgXYKCP9EqF19k6tdX1YKR92r8AgAAKB4CAAM2CYv//PBOAgAAHUoCAAG4mgIABhdII
Date: Thu, 5 Jul 2018 02:32:08 +0000
Message-ID: <1530757910178.45400@cs.auckland.ac.nz>
References: <1530687136897.97792@cs.auckland.ac.nz> <CABkgnnXsM2_PsL_YsuNEh6eDyp-R2d2JRm6OmGFh9nRAV5Lukg@mail.gmail.com> <20180704074101.GA19789@LK-Perkele-VII> <1530691044974.54956@cs.auckland.ac.nz> <20180704081519.GA20000@LK-Perkele-VII> <b8ecb2cfdac0495f188baf9df187c075e70c3a58.camel@redhat.com>, <CAF8qwaBTHfn7iBEaZ9QQ2ueP09Qn4J2s1sBWhqopTzq7eLF6ww@mail.gmail.com>
In-Reply-To: <CAF8qwaBTHfn7iBEaZ9QQ2ueP09Qn4J2s1sBWhqopTzq7eLF6ww@mail.gmail.com>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/2jNyzlsDvqkeT2548E5J_f8dzQk>
Subject: Re: [TLS] Broken browser behaviour with SCADA TLS
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jul 2018 02:32:19 -0000

David Benjamin <davidben@chromium.org>​ 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
configure.

>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
causes.

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

Peter.