[Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
adi at kriegisch.at
Sat Jan 4 00:41:33 CET 2014
Sorry for being rather late in my reply; most of your questions/remarks are
> The guide is not backward compatible with all clients. We, at Mozilla, must maintain
> backward compatibility with even the oldest, most broken, clients on the internet, and
> 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 we could
> just remove these two ciphers, but it's not a realistic goal in the near future.
True. I personally consider unsupported software depreciated and will not
put effort in supporting it.
In case you need to support WinXP and Java6 we discussed a workaround some
months ago: you may simply use the lack of SNI support in those software
stacks to provide a default virtual host with a weaker cipher set hinting
the user to upgrade their clients/cryptostack/os/whatever.
Java7, however, supports SNI -- therefor this will not work for Java7.
Another possibility would be to filter access to certain services (login
for example) based on a cipher white list: only users with strong ciphers
are allowed to access the login page; the rest gets redirected to a
different page. Both of those recommendations are way beyond the scope of
our guide, I guess. And at least the second one is not trivial to get
There is another aspect too: this cipher string is meant to protect secrets
(passwords and the like) for at least some reasonable amount of time, so I
see no way to offer support for Java6 or WinXP (at least with its default
crypto stack). If I understood correctly you are trying to achieve some
kind of opportunistic encryption where it does not matter that much how
strong the crypto around the download really is: if that is the case, you
may just enable 3DES and/or RC4 and you're fine off. But that case is
different for two reasons: First you are a real sysadmin able to choose on
your own (which is excellent btw.) and second there is a difference in
secrets that need protection.
> I *think* they want to prefer CAMELLIA to AES, judging by the published ciphersuite.
> 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.
The intention of the cipher string is to support both: CAMELLIA and AES as
ENISA recommends in their paper too.
That it returns AES first is unfortunate and caused by OpenSSL: all the
CAMELLIA suites in TLSv1.2 aren't implemented in OpenSSL, so e.g. no
CAMELLIA+GCM is available and no CAMELLIA with SHA-2.
The ordering of ciphers by putting SSLv3 (and TLSv1.0) at the end and
prefering TLSv1.2 is obvious (see +SSLv3 in the cipher string).
> ECDSA is explicitely discarded. It doesn't hurt to have it enabled, and
> makes the
> ciphersuite portable to systems that prefer ECDSA certicates (granted,
> it's not that many...).
Yup. We disabled DSA because all our recommendations deal with RSA; adding
DSA would need more research on best practices and the like around DSA.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 827 bytes
Desc: Digital signature
More information about the Ach