Re: [TLS] Broken browser behaviour with SCADA TLS
Peter Gutmann <pgut001@cs.auckland.ac.nz> Tue, 10 July 2018 00:33 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 AB869130E70 for <tls@ietfa.amsl.com>; Mon, 9 Jul 2018 17:33:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level:
X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 l9w0vEMypuEP for <tls@ietfa.amsl.com>; Mon, 9 Jul 2018 17:33:22 -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 14DFD127148 for <tls@ietf.org>; Mon, 9 Jul 2018 17:33:21 -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=1531182802; x=1562718802; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KzTNp6qjbkFF6b06zZxCZieyxbryvkT+28KYeyu5SDc=; b=1xOQfv52Bpa4auTkj5Xuvi4hIEwRkKsdkWd0bXbLYghx1HOCoIYraNns KogpBX1TFVK3drn7TlykhufHoio+wZ108st0ffIKekwyguvAqsqrfplhE Qd3eLNkL1B4MeRvEe47MWsyadXDvPoOrl87YcTlUKA/PyCCqSOcJzIkVz e3CZpyxbe1krQOKf+r4gJ6m4LyEWZSROMUcLQutaoTyJDiXVyM7MN+ldj 6bBSaGuDbg0RB5gL2ifujTwWGj8Q4r4y1z5Pz4PSlwA4FBgByhCSfhCcz dLMh5vfcteVjwIVy4IwKLPsJDrjoj1p9qUWLq11UFcjvYPFsA9nFwiij2 A==;
X-IronPort-AV: E=Sophos;i="5.51,332,1526299200"; d="scan'208";a="20452134"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.2.5 - Outgoing - Outgoing
Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-d.UoA.auckland.ac.nz) ([10.6.2.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 10 Jul 2018 12:33:19 +1200
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.25) by uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.25) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 10 Jul 2018 12:33:19 +1200
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Tue, 10 Jul 2018 12:33:19 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Hubert Kario <hkario@redhat.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Broken browser behaviour with SCADA TLS
Thread-Index: AQHUE2JmEGgXYKCP9EqF19k6tdX1YKR92r8AgAAKB4CAAM2CYv//PBOAgAAHUoCAAG4mgIABhdIIgAYN+oCAAawvkA==
Date: Tue, 10 Jul 2018 00:33:19 +0000
Message-ID: <1531182771058.21025@cs.auckland.ac.nz>
References: <1530687136897.97792@cs.auckland.ac.nz> <CAF8qwaBTHfn7iBEaZ9QQ2ueP09Qn4J2s1sBWhqopTzq7eLF6ww@mail.gmail.com> <1530757910178.45400@cs.auckland.ac.nz>, <8417187.FtxZZQNsAt@pintsize.usersys.redhat.com>
In-Reply-To: <8417187.FtxZZQNsAt@pintsize.usersys.redhat.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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/COoY4gbLuEmdnvCkUf23wncianY>
Subject: Re: [TLS] Broken browser behaviour with SCADA TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.27
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: Tue, 10 Jul 2018 00:33:25 -0000
Hubert Kario <hkario@redhat.com> writes: >There Is No Such Thing As A Trusted Network I didn't say "trusted network", I said "isolated, private network". The type where, if an attacker has got to the point where they have physical access to the area where the network is, they can do far more damage via any kind of non-network attack than they could by hauling in computing equipment and sitting there for hours or days trying to attack the crypto on a particular endpoint. In addition, the security doesn't have to be theoretically perfect, just good enough. An isolated network is frequently deemed secure enough, taking into account the resources being protected, cost to an attacker, likelihood of an attack via that channel, etc. It's typically much easier to control access to a network than to secure every single endpoint on that network, particularly when half of them are a zoo of ethernet-to-something-else converters (if you want to see a mess of interesting TLS, look at industrial RS422/485/Profibus/Modbus/Fieldbus/etc to ethernet converters and TCP gateways, some of those are examples I've used - anonymously - in previous messages). The best example of this, which I've mentioned in the past because it's nicely illustrative, was a ventilator control that used a 512-bit key for its TLS (16-bit device, and it took about 30s for the connection to be established, the key size was chosen because it was all the hardware could handle). This was perfectly adequate, to get access to it you'd need to break into the facility, get to a network port, grab the key from the device, break out again, go away and factor it, break in again, get to the network port, fire up your attack device, and then... you could switch a ventilator on or off. You could also do that by walking down the corridor and flipping a switch. In either case, you've now turned a ventilator in an occasionally-used stock room on or off. Even the 512-bit key was overkill. Peter.
- Re: [TLS] Broken browser behaviour with SCADA TLS Hubert Kario
- Re: [TLS] Broken browser behaviour with SCADA TLS Peter Gutmann
- Re: [TLS] Broken browser behaviour with SCADA TLS Peter Gutmann
- Re: [TLS] Broken browser behaviour with SCADA TLS Salz, Rich
- Re: [TLS] Broken browser behaviour with SCADA TLS Hubert Kario
- Re: [TLS] Broken browser behaviour with SCADA TLS Hubert Kario
- Re: [TLS] Broken browser behaviour with SCADA TLS Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Broken browser behaviour with SCADA TLS Peter Gutmann
- Re: [TLS] Broken browser behaviour with SCADA TLS Martin Rex
- Re: [TLS] Broken browser behaviour with SCADA TLS Nikos Mavrogiannopoulos
- Re: [TLS] Broken browser behaviour with SCADA TLS Ilari Liusvaara
- Re: [TLS] Broken browser behaviour with SCADA TLS Peter Gutmann
- Re: [TLS] Broken browser behaviour with SCADA TLS Peter Gutmann
- Re: [TLS] Broken browser behaviour with SCADA TLS Ilari Liusvaara
- Re: [TLS] Broken browser behaviour with SCADA TLS Martin Thomson
- [TLS] Broken browser behaviour with SCADA TLS Peter Gutmann
- Re: [TLS] Broken browser behaviour with SCADA TLS Hubert Kario
- Re: [TLS] Broken browser behaviour with SCADA TLS Martin Thomson
- Re: [TLS] Broken browser behaviour with SCADA TLS Salz, Rich
- Re: [TLS] Broken browser behaviour with SCADA TLS Kurt Roeckx
- Re: [TLS] Broken browser behaviour with SCADA TLS David Benjamin
- Re: [TLS] Broken browser behaviour with SCADA TLS Colm MacCárthaigh
- Re: [TLS] Broken browser behaviour with SCADA TLS David Benjamin
- Re: [TLS] Broken browser behaviour with SCADA TLS Peter Gutmann
- Re: [TLS] Broken browser behaviour with SCADA TLS Peter Gutmann
- Re: [TLS] Broken browser behaviour with SCADA TLS Peter Gutmann
- Re: [TLS] Broken browser behaviour with SCADA TLS Ilari Liusvaara
- Re: [TLS] Broken browser behaviour with SCADA TLS Peter Gutmann
- Re: [TLS] Broken browser behaviour with SCADA TLS Adam Langley
- Re: [TLS] Broken browser behaviour with SCADA TLS Martin Rex
- Re: [TLS] Broken browser behaviour with SCADA TLS Martin Rex
- Re: [TLS] Broken browser behaviour with SCADA TLS Martin Thomson
- Re: [TLS] Broken browser behaviour with SCADA TLS Peter Gutmann