Re: [TLS] Broken browser behaviour with SCADA TLS

[Peter Gutmann <[e-mail]>]

David Benjamin <[e-mail]>​ writes:

>The bad feedback was not even at a 2048-bit minimum, but a mere 1024-bit
>minimum. (Chrome enabled far more DHE ciphers than others, so we encountered
>a lot of this.) 2048-bit was completely hopeless. At the time of removal, 95%
>of DHE negotiations made by Chrome used a 1024-bit minimum.

How does Google, rather than the people running the systems being connected
to, know that 1024-bit DH isn't secure enough for a given environment?  The
majority of this stuff is running on isolated, private networks or inside VPN
tunnels for which pretty much anything, including 512-bit keys, are fine.

It's also somewhat disturbing that Chrome now walks straight past a perfectly
good PFS DHE suite and instead goes to a problematic pure-RSA one instead.

>You should instruct these folks to configure ECDHE+RSA ciphers if they have
>RSA keys. 

The devices don't do ECDHE, and they probably never will (at least until the
next upgrade cycle, which could take a decade or more), so there's nothing to
configure.

>rfc7919, did not fix the problem. This was pointed out here, but never
>incorporated to the document:

Yep.  The issues were pointed out by several people before it was published,
but got published anyway... with the result being that a number of
implementations chose not to support it because of the problems that it
causes.

>Particularly in the second scenario, it seems they're already implemented,
>just the server was incorrectly configured to use the wrong ones.

That was in my testing, not using a PLC control centre or similar, in other
words the actual devices being used in the field.  Doing that would have
required a firmware reload for each test, which is way too painful to think
about.  For "server incorrectly configured", see above, they were offering all
the suites the firmware and hardware supported.

Peter.