Hi, Sorry for crossposting this to three lists but I feel this is a multi-software-issue and I feel all software involved need to find a way to resolve this.
I feel the current software setting of tls server configs and browsers leads to the unoptimal result that often CBC modes are preferred over authenticated encryption GCM-modes. There seems to be widespread agreement that TLS-CBC-Modes are not optimal and should be avoided (Padding oracles, Lucky Thirteen etc.) Firefox and Chrome support authenticated encryption via TLS 1.2 and GCM these days. However they have for some reason decided not to support AES-256 but only AES-128. This is in itself no problem because there is no reason to believe AES-128 is not safe. But it leads to the probably unintended consequence that often AES-256-CBC is preferred over AES-128-GCM. Take this scenario: * Server operator uses apache+openssl wiht cipher string "HIGH:!MEDIUM:!LOW:!aNULL@STRENGTH". This seems reasonable. Only HIGH security ciphers and sort them by strength. * Browser (Chrome or Firefox) will take the first preferred cipher suite it supports. As it doesn't support AES-GCM-256 it will choose AES-CBC_256. What can be done to avoid this? a) First of all server operators can do more manual work and sort ciphers on their own. However it's probably not desired that every server operator needs to know the inner details of TLS. b) OpenSSL changes so that it considers GCM-modes always more secure than CBC modes and sorts them to the front. c) Browsers could start supporting AES-256-GCM d) Browsers could stop supporting AES-256-CBC Each of these would solve the issue, they don't exclude each other (in theory you could do all of them). I feel b) should happen anyway and probably one of c) or d). If browsers feel AES-128 is "good enough" they could just remove AES-256 support completely. If they feel they want AES-256 in the unlikely case that attacks against AES improve by a great margin then there is no reason not to support AES-256-GCM. It feels illogical to support AES-256, but only in its less secure mode. Thoughts? cu, -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42
pgpqaniJapD9b.pgp
Description: OpenPGP digital signature
_______________________________________________ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
