[Ach] Modernizing Cipherstrings (once again) [Re: Looks like SSLv3 is enabled for httpd in spec?]
pepi.zawodsky at maclemon.at
Fri Mar 4 16:38:27 CET 2016
> On 03 Mar 2016, at 23:32, Aaron Zauner <azet at azet.org> wrote:
> I’ve been one of the main proponents for removing CAMELLIA
Firefox was the last Browser to actually support CAMELLIA and this support has recently been removed. So there is currently no Browser that I know of still supporting CAMELLIA.
We must update the cipher suites to accomodate the requirements of HTTP/2 and in lieu of upcoming TLS 1.3 anyway. This is the perfect opportunity to remove outdated cruft after two years of out stuff holding up surprisingly well, and maybe also include the new hotnesses like Chacha20, Poly1305, etc.
> While we're add it; especially for HTTPS: I think it would make a lot of sense to get rid of the Cipherstring-A. It’s not used anywhere in the actual Applied Crypto Hardening document and I think current browsers will have a hard time establishing any connection with that preferred suite.
With HTTP/1.0 and HTTP/1.1 it actually works, it runs into a blacklist issue with HTTP/2. If one needs something like Cipherstring-A it’s most likely best to explicitly spell out only the few suites one desires.
> DHE needs to be either gone or put at the end of our cipherstring.
> OpenSSL provides the option SSL_OP_SINGLE_DH_USE for ephemeral DH (DHE) in TLS. It is not on by default. If the option is not set then the server reuses the same private DH exponent for the life of the server process and would be vulnerable to this attack. It is believed that many popular applications do set this option and would therefore not be at risk.
> ``` -- https://www.openssl.org/news/secadv/20160128.txt
Additionally the SSL_OP_SINGLE_DH_USE option **has been switched on by
default and cannot be disabled**. This could have some performance impact.
Obviously only helps those who keep their stuff updated.
I agree moving DHE after ECDHE but still before plain RSA for last-resort legacy clients.
> By now we should prefer ECDSA with the default supported NIST curves until something better comes along (it's already at that stage in IETF, we just need to wait for clients and servers to implement - some already do like OpenSSH). This gives us better performance, shorter keys and we avoid a couple of weird DH(E) specific corner-cases like the one I pointed to above. This is also what the Mozilla Server Security Guide has been recommending right from the start. We did well to wait out and see. But by know the research community is pretty clear that these curves are *not* backdoored (https://eprint.iacr.org/2015/1018.pdf), so why not use them - it's elegant crypto?
Is there anything about the DSA nonce issues with bad randomness that we need to take care of? Did I miss something, or misunderstand something?
So much I have to learn. :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Ach