On Wed, Jul 4, 2018 at 4:41 AM Nikos Mavrogiannopoulos <n...@redhat.com> 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 <ilariliusva...@welho.com> 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: 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.)
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
