Re: [TLS] Broken browser behaviour with SCADA TLS

[Ilari Liusvaara <[e-mail]>]

On Wed, Jul 04, 2018 at 05:05:08PM +1000, Martin Thomson wrote:
> On Wed, Jul 4, 2018 at 4:53 PM Peter Gutmann <[e-mail]> 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