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.