[Ach] Modernizing Cipherstrings (once again) [Re: Looks like SSLv3 is enabled for httpd in spec?]

[Aaron Zauner]

> On 02 Mar 2016, at 15:41, Hanno Böck <hanno at hboeck.de> wrote:
> 
> On Wed, 2 Mar 2016 15:33:29 +0100
> Martin <rc6encrypted at gmail.com> wrote:
> 
>> For httpd the spec says
>> 
>> SSLCipherSuite
>> 'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA256:EECDH:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!IDEA:!ECDSA:kEDH:CAMELLIA128-SHA:AES128-SHA'
> 
> I'm not exactly sure what the camellia crap is doing there and this
> looks fishy and overly complicated to me in many ways, but anyway:

Because - you know - what if AES is backdoored by NSA or something. Like the NIST curves we now know obviously were!111 [mind the sarcasm!]

I've been one of the main proponents for removing CAMELLIA for (actually --) years now! I still have to see a valid readon to keep it in there other than "it's not AES", which is not an argument anyone would try to defend against an academic audience. So let's be reasonable. I've called for that a lot of time, let's get rid of it once and for all. We do not support ARIA either. So why e.g. CAMELLIA? AES is USG approved, CAMELLIA is approved by Japanese government, ARIA is approved by South Korea. That's the reason they're in there in the first place. But NIST recommendations are adopted outside of the US as well. We're probably the only big project pushing asian government ciphers that haven't seen anywhere near the amount of cryptanalysis that AES has seen since it's inception. Yea it's possible that someone finds an attack on AES, though extremely unlikely, especially a non-academic one. But then again; this means it should be far easier to find new attacks on CAMELLIA and ARIA because of zero research interested there in the past. AES has been the prime target for everyone out to make a name for himself.

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.

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

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?

Aaron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.cert.at/pipermail/ach/attachments/20160303/18b737a0/attachment.sig>