IETF Logo Mail Archive

Re: [TLS] Broken browser behaviour with SCADA TLS

Peter Gutmann <pgut001@cs.auckland.ac.nz> Thu, 05 July 2018 12:05 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 F3B5A1277BB for <tls@ietfa.amsl.com>; Thu, 5 Jul 2018 05:05:12 -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 sxVfSSt5MO_R for <tls@ietfa.amsl.com>; Thu, 5 Jul 2018 05:05:06 -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 800A6130DE4 for <tls@ietf.org>; Thu, 5 Jul 2018 05:05:04 -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=1530792305; x=1562328305; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VjH1TyEySi2B6/Iv6mci+0m0OCnkZTDdlyXehbyL2Hk=; b=UqG3cfRRJ7Nhy1eogBnOVn5WZ41TZzuPJ+HMpuWkl/WoHqodwN15k/LE EzCS/zyJ63WhD7z14QJpLjG2nfBygyyXt6JZb6259l/03ZWQO97AM45L7 /tretgD7llBInxPzYHVeyffmcVD2zZ3hkt268twgN2kQj364JpetT//+c Ga0DWPHd1wiWhlIvqcAsG9IyTU06XR0e0ZDdoweujjU8X3w7PypsIlQ5u G0Ge1yfY1cZtxEl2/1T1n1V0cSydYiYPw2xvId0Gr3LA11bWh63b6hnIW gsf8SWritxiEn7gNaxG31YtHb5Cki5zY5UfDS1Ik6V2TZ0TgkHGdn/tN+ w==;
X-IronPort-AV: E=Sophos;i="5.51,312,1526299200"; d="scan'208";a="19769706"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.2.3 - Outgoing - Outgoing
Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-b.UoA.auckland.ac.nz) ([10.6.2.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 06 Jul 2018 00:05:02 +1200
Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-ogg-b.UoA.auckland.ac.nz (10.6.2.23) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 6 Jul 2018 00:05:02 +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; Fri, 6 Jul 2018 00:05:02 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
CC: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] Broken browser behaviour with SCADA TLS
Thread-Index: AQHUE2JmEGgXYKCP9EqF19k6tdX1YKR92r8AgAAKB4CAAM2CYv//PBOAgAHzICX//4XzgIABInIY
Date: Thu, 05 Jul 2018 12:05:01 +0000
Message-ID: <1530792281962.34902@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> <1530756106390.98539@cs.auckland.ac.nz>, <20180705064455.GA7996@LK-Perkele-VII>
In-Reply-To: <20180705064455.GA7996@LK-Perkele-VII>
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/uFE5HlHPfFrBHbFU0pHzaR-ig64>
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 12:05:13 -0000

Ilari Liusvaara <ilariliusvaara@welho.com> writes:

>1) Advertise DHE, accept weak groups. Vulernable to LOGJAM.

Only if the weak groups you accept are 512 bits.

A bigger question is, why does Chrome think it's up to it to decide whether
the device user's choice of key size is appropriate or not?  As I mentioned
earlier, in many cases 1024-bit keys are not only perfectly fine but more than
enough.  In fact given the hardness of the DLP they're probably OK in
virtually all cases as long as everyone doesn't share the same group2 prime.

The crazy thing is that although Chrome rejects a connection to a PFS,
relatively safe (via the DLP's hardness) 1024-bit DHE server, it's perfectly
happy connecting to a far less safe (both in terms of factorability and use of
pure RSA) 1024-bit RSA server.  

This is "security" done backwards!

Peter.

v2.23.0 | Report a Bug | By Email