So I went over the https://wiki.mozilla.org/Security/Server_Side_TLS article with a bit more attention to detail and I think we should extend it in few places.
Especially if it is supposed to be also the general recommendation for servers, not just for ones that are part of Mozilla network. The items that probably should be changed or added: * curves weaker than secp256r1 - I think they shouldn't be enabled at all - while browsers do enable only the two or three NIST curves, clients that use OpenSSL enable also the rather weak 163 bit curve, making it possible to negotiate them (and as such limit the level of security to about 80 bit) * negotiation of curves in ECDHE - servers in general should be able to negotiate the used curve for this KEX - it's a RFC MUST * lack of secp256r1 intolerance - servers that hardcode this curve may ignore the tls extension completely, causing the connection to fail if the client doesn't support this curve (the server should choose a cipher that doesn't require ECC in such case) * SHA1 signing of (EC)DHE in TLSv1.2 - there's a bug in OpenSSL that causes the SNI certificate selection to not copy acceptable signature algs properly, this causes it to sign the key exchange using SHA1. Some servers may just hardcode the sig alg, which would be just as bad * SHA-384 and SHA-512 signatures in certs - in current version they are not acceptable - as they are stronger, I think they should be added as acceptable (but maybe marked as not recommended). SHA-224 should probably be explicitly marked as non recommended as it is not supported in some libraries that do support SHA-256 and greater (very old NSS had this issue) * ECDSA certs (and prioritisation of ECDSA above RSA) - there's no mention of those, and since we suggest PFS over non-PFS and ECDHE-ECDSA is over twice as fast as ECDHE-RSA[1], I think we definitely should allow (if not recommend) its use * intolerance of TLS1.3 ClientHello - new version is incoming while a significant percentage of servers can't do TLS version negotiation properly While most of those items may become issues only in future, I think it's better to point to them now, so that the number of servers that have bad configurations/bugs is limited. As such, it will also limit the need for clients to do the TLS downgrade dance. 1 - https://securitypitfalls.wordpress.com/2014/10/06/rsa-and-ecdsa-performance/ -- Regards, Hubert Kario -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
