Hi! > > the Result is: > > $ openssl ciphers -v > > '-ALL:ECDH+aRSA+AES:DH+aRSA+AES:aRSA+kRSA+AES:+AES256' | cut -f1 -d" " > > ECDHE-RSA-AES128-GCM-SHA256 > > ECDHE-RSA-AES128-SHA256 > > ECDHE-RSA-AES128-SHA > > DHE-RSA-AES128-GCM-SHA256 > > DHE-RSA-AES128-SHA256 > > DHE-RSA-AES128-SHA > > AES128-GCM-SHA256 > > AES128-SHA256 > > AES128-SHA > > ECDHE-RSA-AES256-GCM-SHA384 > > ECDHE-RSA-AES256-SHA384 > > ECDHE-RSA-AES256-SHA > > DHE-RSA-AES256-GCM-SHA384 > > DHE-RSA-AES256-SHA256 > > DHE-RSA-AES256-SHA > > AES256-GCM-SHA384 > > AES256-SHA256 > > AES256-SHA You do notice that you prefer non-ephemeral ciphers over ephemeral ones here, right? As the fallback cipher you only ever need AES256-SHA and nothing else to support legacy-old-really-old-legacy versions of openssl at the very end of the cipher string.
Things with CipherB started getting messy when we added AES128 due to sorting issues throughout all the different openssl versions. As soon as Chacha20/Poly1305/ED25519 hits openssl in distros, we will need to take a different road anyways. Another design decision was the question whether to trust the NIST curves or not. Sure, performance of ECDHE is better than that of DHE, but our recommendations aren't directed to high traffic sites in the first place but to small to medium sized networks who most probably won't see a difference here. With ED25519 most probably entering TLSv<NEXT> that part of the game changed, but we will still have to deal with it (ie choosing only ed25519). For reasons I do not completely understand, browser vendors do only implement (or make available) certain TLS1.2 ciphers like ECDHE-RSA-AES128-GCM-SHA256 but not their AES256 equivalent. The question is how we want to deal with that in the future. For now, getting CipherB as it is now consistent in the document should be priority A; moving forward to either CipherB v2 or splitting distro support by having CipherB-legacy and CipherB-current could be the way to go; but this will require further discussion. -- Adi
signature.asc
Description: Digital signature
_______________________________________________ Ach mailing list [email protected] http://lists.cert.at/cgi-bin/mailman/listinfo/ach
