Non-obsolete crypto is relatively easy to achieve with Chrome and Firefox, but not as much with IE and Safari, and many other clients.
There's no doubt that sites with authenticated crypto should get a better score, but it's not straightforward to establish fair criteria. For example, should SSL Labs penalise sites that don't use authenticated encryption with IE? Because, to do that, you must either accept the DHE key exchange or deploy with dual (RSA and ECDSA) keys. The former is slow, while the latter requires more effort.
You could say that SSL Labs should focus only on the cases where it is possible to use authenticated encryption, but that creates another problem: should SSL Labs report the reality, or award best effort? It's not easy to decide, but so far I've been leaning toward the reality.
Finally, there's the case of using ChaCha20/Poly1305; should SSL Labs encourage the use of cipher suites that are not yet standardised? Should Google get a pass because we "know" they know what they're doing?
And yes: you should be encouraging Salsa/Poly1305. They're de facto standards, and will very soon be de jure standards as well. Plenty of other "nonstandard" behavior is encoded into TLS. It's also not fair to call Salsa/Poly1305 a "Google" initiative.
Making the effective top grade a B might also reduce the physiological motivation for improving a seriously bad TLS config. At least in the US, anything less than an A is considered very close to failing these days (it's silly, but it's the reality). Making changes just to get a B isn't nearly as motivational as making changes to get an A.
And to be clear, I'm not saying we shouldn't be moving away from the CBC ciphers as fast as possible - just that dishing out a B grade for supporting a large number of users is not a good way of accomplishing that.
* Grade 'A' requires AES-GCM and ChaCha20Poly1305
* Allow CBC for 'A' iff it's a last resort option
* Use nginx equivalent of "ssl_prefer_server_ciphers on;"
CBC would then only be used by clients that don't support AE ciphersuites.
I think not negotiating GCM on a browser where GCM is available and not using it will produce a warning should cap the mark at a B.
Understood re: IE.
Agreed re: ChaCha20/Poly1305, at least until openssl ships it (and maybe longer).
> Finally, there's the case of using ChaCha20/Poly1305; should SSL Labs encourage the use of cipher suites that are not yet standardised?
Ie, I don't think it's worth encouraging CHACHA20/POLY1305 until people can use it.
We need to get away from the idea that it's unfair to recognize superior cryptography merely because it's currently only implemented in Chrome.
The grade either reflects the actual quality of a server's TLS configuration, or it reflects something else.
In any case, it's a moot point here, because ChaCha20/Poly1305 is RFC7593.
Accepting non-standard crypto is a slippery slope, which is why I'd rather take a very conservative approach.
P.S. You mean RFC 7539, which came out only a couple of days ago. Now we only need another RFC for the use in TLS.
That doesn't change that people won't use it until it's in openssl properly and they don't have to maintain a patched version themselves.
There are two options: enable the only modern native stream cipher available for TLS, and with it the only polynomial MAC that doesn't require hardware support (and thus the best polynomial MAC available for mobile devices), or don't.
The former option is superior to the latter option. The latter option is easier, but: nobody said engineering was supposed to be easy.
Either SSL Labs is evaluating the quality of TLS implementations, or they're evaluating something else. Arguments like the ones I see on this thread suggest it's "something else".
Other platforms should also keep up to date with browser changes. Cipher suites are a balancing act between compatibility and security, that's why Mozilla's Server Side SSL let's you pick the compatibility you wan. But that doesn't mean eg, Apache or nginx couldn't provide better defaults in newer releases (they may be planning to do so already).
Reply to realusername's comment below (rate limit):
Not offended at all! I think concentrating the discussion amongst people who have the time to look into this, then having those decisions flow down to projects as defaults makes the web more secure. Mozilla's https://wiki.mozilla.org/Security/Server_Side_TLS project informed the node changes: hopefully it will also inform the defaults for eg the next nginx.
Reply to derefr's comment (rate limit):
Mozilla Server Side TLS is that set of agreed upon conventions. The Moz logic is great, since the conventions produce 3 sets of cipher suites with different compatibility / security tradeoffs.
We made https://www.npmjs.com/package/ssl-rsa-strength as a library implementing Mozilla's logic a little while ago.
What we need is a "library" that just hardcodes agreed-upon conventions on top of OpenSSL. Import that instead of OpenSSL, use its API (which would be mostly transparent calls through to OpenSSL using the current best practices), and everything gets taken care of. New best practices? Updated library package.
The idea of a library to implement that logic is solid: we made https://www.npmjs.com/package/ssl-rsa-strength as a library implementing Mozilla's logic a little while ago.
Web browser developers need to make some decisions to make clear what is safe, probably safe, and an threat. Lumping wrong, but probably safe things in with threats means that users will ignore threats. Look at the history of Windows and users just clicking dialogue boxes without reading.
These changes in Chrome are teaching them that the red marks on the location bar are just a normal part of those interactions.
Normal users don't want to deal with the technicalities. Presenting information to the user is just a way to "do something" while not actually taking responsibility and solving the problem.
That's exactly the mindset that put us in this horrible situation. People would start warning against bad crypto much sooner if the consequences weren't as bad as browsers made them. We could even have warnings against plain HTTP already if browser security wasn't this radical.
My understanding is that this happens because of cross-signing, where some intermediates are using SHA1. Just in the last couple of days I had users complaining about two different sites with certificates from two CAs.
Yesterday, the latest version of NSS was finally uploaded to Debian Unstable, fixing the problem there, but Debian Stable is still affected, and will be until it's updated either through a security update or a stable point release. I plan to agitate for this if necessary.
Here's the relevant Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774195
Anyway I asked a factual question, I would like an answer.
The cipher list below (for apache) should work just fine with XP/IE8 and later, but still net you an A+ in ssl labs, with a bit of other work.
SSLProtocol All -SSLv2 -SSLv3
But people on old browsers may be served RC4 and get "obsolete cryptography" as their message.
SSL Labs instead gives a holistic approach and thats why it considers the best and worst potential set up.
 I'm handwaving the version fallback. You'll want to also support FALLBACK_SCSV, which SSLLabs also checks for, until that thing is gone for good.
We're going to lose this fight unless we can make this easier. I mean, I care and I should be capable of working this out, but I'm no security expert - it's just too much work and most of the information is totally incomprehensible to me so I end up not bothering. I'm sure I'm not alone.
Then, I use Mozilla's SSL configuration generator (https://mozilla.github.io/server-side-tls/ssl-config-generat...) to set up the cypher suite.
Those two together will have get you running very quickly. It's certainly a good idea to know what you're dealing with, but there are smart people behind both of these services that really simplify things.
For example firefox mentions SHA-1 insecurity when visting the google jquery CDN.  Chrome doesn't seem to care however and there are other sites where it is vice-versa.
I was deploying a virtual appliance and was baffled as to why I was unable to load the configuration web page from both Chrome and Firefox, until I visited the vendors web page and downloaded a hotfix that removed the SHA-1 certificate. This was an appliance released in 2015. It's a shame that the software vendor is releasing insecure virtual appliances, but it's also a shame that Google and Mozilla can't get their act together enough to display an informative error message.
How about "The site you are attempting to visit uses weak cryptographic algorithms, so the connection has been blocked."
And, please give advanced users a way to click through anyway. If this is a virtual appliance I'm deploying in an isolated network and I'm trying to access the administrative page, I should be allowed to get there, without some nanny state browser manufacturer determining that my crypto isn't safe enough.
This already exists, and you can find it by reading through the source of Chromium.
That's the right way to do it.
The Developer version should start complaining about outdated crypto years before the mainstream one. It should complain just after it's shown broken, and something better is available. Even if any attack is too expensive to perform.
It's just frustrating that there are so many different configurations to keep track of, it just feels like the whole hosting / cert industry has not handled this particularly well.
I asked David Benjamin from Chrome and right now, sub resources aren't included in Chrome warnings (he thinks they should be though):
There's even a set on config for poor sysadmins who are forced to support legacy clients on XP.
Happy to answer questions as well - I do this for work.
They cover (in little detail, and with some errors) evolutionary theory, but they say it's obsolete and then give you the flavor-of-the-month creationist justification as "what's current".
At the same time we are trying to push every website (including blogs, little-league clubs, joke sites) to https-only.
ECDHE or gtfo :(