Re: [TLS] Broken browser behaviour with SCADA TLS

[David Benjamin <[e-mail]>]

On Wed, Jul 4, 2018 at 11:15 AM David Benjamin <[e-mail]>
wrote:

> On Wed, Jul 4, 2018 at 4:41 AM Nikos Mavrogiannopoulos <[e-mail]>
> wrote:
>
>> On Wed, 2018-07-04 at 11:15 +0300, Ilari Liusvaara wrote:
>> > On Wed, Jul 04, 2018 at 07:57:41AM +0000, Peter Gutmann wrote:
>> > > Ilari Liusvaara <[e-mail]> writes:
>> > >
>> > > > More serious problem is servers returning too small modulus due
>> > > > lack of
>> > > > negotiation. Which was the reason why Chrome disabled DHE.
>> > >
>> > > Why not reject the handshake if the modulus is too small, rather
>> > > than
>> > > disabling all DHE suites on the off chance that the server returns
>> > > a value you
>> > > don't like?
>> >
>> > Chrome initially did that. It caused quite a lot of bad feedback from
>> > owners of various bad embedded stuff. The thread on relevant forums
>> > was
>> > quite something. Hundreds of messages blaming Google for breaking
>> > stuff.
>>
>> We had similar experience when we required a minimum of 2048-bit
>> modulus for all TLS connections in Fedora 28 beta irrespective of back-
>> end lib. It broke connections to VPN servers and web internal web sites
>> and we had to revert the change. The DHE ciphersuites under TLS1.2 seem
>> doomed and rfc7919 couldn't save them.
>>
>
> Indeed. 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.
> See here for details:
>

Oops, that sentence should have read:

"At the time of removal, 95% of DHE negotiations made by Chrome used a
1024-bit *group*."

That is, were we to have enforced a 2048-bit minimum, 95% of DHE
connections would have broken. With 5% of it salvageable, the TLS DHE code
points are not worth saving.


>
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/ShRaCsYx4lk/46rD81AsBwAJ
>
> I should add to that link that the "draft specification which fixes the
> negotiation problems", now rfc7919, did not fix the problem. This was
> pointed out here, but never incorporated to the document:
> https://www.ietf.org/mail-archive/web/tls/current/msg18697.html
>
> To the original email, it seems the second and third scenarios are
> identical. Configuring ECDHE+ECDSA ciphers is a no-op if using an RSA
> server key. The third and fourth scenarios are indeed unsurprising for a
> browser that doesn't support DHE. You should instruct these folks to
> configure ECDHE+RSA ciphers if they have RSA keys. Particularly in the
> second scenario, it seems they're already implemented, just the server was
> incorrectly configured to use the wrong ones.
>
> DHE at acceptable sizes is quite slow anyway, so their servers may well
> appreciate the speed boost. (Indeed, I often see DHE disabled in server
> deployments as otherwise the poor servers would melt.)
>