Re: [TLS] Broken browser behaviour with SCADA TLS

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 04 July 2018 07:42 UTC

Return-Path: <ilariliusvaara@welho.com>
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 1E121130DFD for <tls@ietfa.amsl.com>; Wed, 4 Jul 2018 00:42:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 eRG2uGnwiESW for <tls@ietfa.amsl.com>; Wed, 4 Jul 2018 00:42:33 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 937FA130DF0 for <tls@ietf.org>; Wed, 4 Jul 2018 00:42:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 386F94FAD7; Wed, 4 Jul 2018 10:42:31 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id QsAEStzRml0U; Wed, 4 Jul 2018 10:42:30 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 62C3E72; Wed, 4 Jul 2018 10:42:28 +0300 (EEST)
Date: Wed, 4 Jul 2018 10:41:01 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Message-ID: <20180704074101.GA19789@LK-Perkele-VII>
References: <1530687136897.97792@cs.auckland.ac.nz> <CABkgnnXsM2_PsL_YsuNEh6eDyp-R2d2JRm6OmGFh9nRAV5Lukg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CABkgnnXsM2_PsL_YsuNEh6eDyp-R2d2JRm6OmGFh9nRAV5Lukg@mail.gmail.com>
User-Agent: Mutt/1.10.0 (2018-05-17)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/NL68C_S5ljBXQoH4w-Pix9UJ1oQ>
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: Wed, 04 Jul 2018 07:42:37 -0000

On Wed, Jul 04, 2018 at 05:05:08PM +1000, Martin Thomson wrote:
> On Wed, Jul 4, 2018 at 4:53 PM Peter Gutmann <pgut001@cs.auckland.ac.nz>; wrote:
> > ... Client negotiates non-PFS pure-RSA and ignores PFS DHE ...
> 
> How is the client doing any of this?  The server picks the cipher suite.
> 
> > Least broken browser: Firefox (at least for the last proper version they released)
> 
> Newer versions might not have DHE, which I hope is consistent with
> your expectations.  But we haven't started on those plans.  As of the
> latest version, things should be the same - extensions shouldn't
> affect whether connections work.
> 
> The problem with DHE of course being that it uses the TLS 1.0 suites
> with the SHA1 MAC and with the MAC and encrypt in the wrong order.
> And that it is subject to small subgroup attacks from the server
> unless it negotiates the FFDHE extension.

More serious problem is servers returning too small modulus due lack
of negotiation. Which was the reason why Chrome disabled DHE.


Also, there are finite-field AEAD ciphersuites in TLS 1.2, which do
not use the broken blockmode nor SHA-1 (but Firefox does not appear to
support any of these):

- AES, ARIA or CAMELLIA in GCM mode, with 128 or 256 bit keys, and with
  RSA or DSS certificate (good luck getting DSS certificate, and even
  more luck getting clients to accept it).
- AES in CCM mode, with 128 or 256 bit keys and 64 or 128 bit tags. Only
  RSA certificates are supported.
- CHACHA20-POLY1305-AEAD with 256 bit keys. Only RSA certificates are
  supported.



-Ilari