[Cryptography] What TLS ciphersuites are still OK?

Phil Pennock md-cryptography at spodhuis.org
Mon Sep 9 22:28:55 EDT 2013

Hash: RIPEMD160

On 2013-09-09 at 23:14 +0200, Hanno Böck wrote:
> Also, DHE should only be considered secure with a large enough modulus
> (>=2048 bit). Apache hard-fixes this to 1024 bit and it's not
> configurable. So there even can be made an argument that ECDHE is more
> secure - it doesn't have a widely deployed webserver using it in an
> insecure way.

Bear in mind that TLS does not include D-H parameter size negotiation
and various deployed clients and servers have under-documented fixed
lower and upper bounds on the sizes.  When those bounds are breached,
what tends to happen is that TLS negotiation fails.

At that point, the common approaches seen today are to throw up an error
message (site down) or fallback to cleartext, *not* to disable the D-H
suites and try TLS again.

When I recoded Exim's GnuTLS integration, I originally made the D-H
parameter generation just ask GnuTLS what sizes I should feed it for
"NORMAL", in an attempt to get Exim out of the policy business and to
trust the crypto libraries.  I discovered the hard way that this value
was higher than the upper-bound of the NSS crypto library, so that
change made Thunderbird unable to talk to those release candidates of
Exim.  I had to write new security-parameter handling code during the RC
series to work around this interoperability issue.

The NSS upper limit was 2236 bits.  Meanwhile, I discovered in the past
week or so that prior to Exim 4.80 (when I redid the integration),
Debian were patching the Exim code so that on Debian Exim installs the
configured minimum acceptable size of D-H parameters was 2048 bits.
Most sites were probably configuring 1024, or using Debian, so we had a
source of real-world TLS breakage in mail-systems.  Fortunately, that
affects TLS-as-a-client from an MTA, where there's no trustworthy
concept of remote identity yet (but DANE is changing that) so no host
identity to verify, so the TLS between mail-servers that haven't
configured stronger policy out-of-band is only protection against
passive sniffing, at best.

If folks are going to seriously start looking at how TLS can be improved
in ways which make it less likely for systems to fail catastrophically,
then *some* kind of D-H size limit negotiation, with clients able to
decide to avoid D-H (if that's otherwise acceptable to policy) is pretty
much required if the parameter sizes are ever to be changed to more
useful values in real-world deployments.

Apache are being conservative, but not without reason.

- -Phil


More information about the cryptography mailing list