[Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
julien at linuxwall.info
Thu Jan 2 18:09:07 CET 2014
On 2013-12-29 18:30, Kurt Roeckx wrote:
> On Sun, Dec 15, 2013 at 11:22:32AM -0500, Julien Vehent wrote:
>> For the same reason, the server ciphersuite that we recommend at
>> does not drop Camellia, but lists it at the bottom of the ciphersuite.
>> It's a safe choice, but not one that we recommend.
> You might also want to read:
[cc-ing the cert.at mailing list that published this guide]
Thanks for the link! I wasn't aware of this guide.
Overall, I think this guide is great! The configuration examples are very
It's also good to have multiple TLS guides with different audiences, so I'm
glad to see more people take on the issue.
I need to do a thorough read of the entire thing. I am a bit puzzled by some
choices made around their ciphersuite "B" (the most realistic and practical
of the ciphersuite construction sections are still empty, so it's hard to
what exactly is intended. I did notice a few things that I, personally, find
Why prefer DHE to ECDHE, when the former is 3 times slower than the later?
There is a bit of a justification in 3.5:
"Since there is much discussion on the security of ECC, flawed settings
well compromise the security of the entire system."
I wish there was references to these "discussions". My understanding of the
the art of ECC is that P-256 is considered at least as secure as DH and RSA.
They recommend AES-128 in "3.4. Keylengths", but publish a ciphersuite that
AES-256 (see below). This is probably just an oversight, the guide is still
The guide is not backward compatible with all clients. We, at Mozilla, must
backward compatibility with even the oldest, most broken, clients on the
this shapes our guidelines. For example, the ciphersuite B doesn't contain
3DES or RC4,
and is therefore unusable on *a lot* of PC that still run Windows XP. I wish
just remove these two ciphers, but it's not a realistic goal in the near
Same goes for the recommendation to use DH parameters > 1024 bits. We tried
using a 2048
bits parameter a few months back. We first noticed a big spike in CPU usage,
the largest exponentiation, but that was still acceptable. What forced the
the long list of java 6 clients that broke, because they don't accept DH
keys > 1024 bits.
Until all of these clients get fixed, DH params will be limited to 1024
I *think* they want to prefer CAMELLIA to AES, judging by the published
But the construction must be wrong because it returns AES first. If the
intent is to
prefer Camellia, then I am most interesting in the rationale.
ECDSA is explicitely discarded. It doesn't hurt to have it enabled, and
ciphersuite portable to systems that prefer ECDSA certicates (granted, it's
not that many...).
$ openssl ciphers -v
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256)
DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256)
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256)
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256)
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128)
DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128)
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128)
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128)
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256)
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256)
ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256)
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128)
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128)
ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128)
CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256)
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256)
CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128)
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128)
OpSec @ Mozilla
More information about the Ach