Hacker News new | past | comments | ask | show | jobs | submit login

(Author of SSL Labs here.) From Chrome's perspective, it's easy to complain about obsolete cryptography because it takes only its connections into account. When you take a wider view and include other browsers, all sites today effectively must use obsolete cryptography because client-side support for authenticated suites is not yet strong. Even Google would have a "uses obsolete crypto" warning because it negotiates CBC suites with, say, Safari.

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?

I don't understand why AE ciphersuites can't just own the 'A' grade, and everything else be a 'B' and below. You are currently awarding an 'A' "for effort". You should stop, now. We're all adults here.

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.

There are still many clients out there that do not support AE ciphersuites (e.g. literally every version of Safari). If SSL Labs capped the grade at B for supporting these clients, then the top grade at SSL Labs would effectively become a B, as no serious site would get an A grade anymore. It wouldn't actually accelerate the transition away from these clients/ciphers.

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.

Those older clients are actually vulnerable to real cryptographic flaws in TLS.

Which flaw, specifically, would the latest version of Safari be vulnerable to?

I guess it depends on your confidence in the Lucky 13 patch, right?


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.

You and tptacek are both right, so how about the following to combine your positions:

* 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.

Hi Ivan! Article author here, your book is setting on my desk as I type this. The article is simply meant as an explanation to users.

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).

Why would "OpenSSL shipping it" make a difference? It's not like Poly1305 is the only MAC available in the "modern cryptography" bucket; you can use AES-GCM as well.

That was a specific response to:

> 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.

They can, if they're using Chrome.

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.

I am not completely against de-facto standards, but, in the TLS space, Chacha20/Poly1305 is not one. At this time it's mostly used only by Google/Chrome (AFAIK, no other clients support it); we'd need to see better browser support (multiple organisations) and wider server-side support before we can accept it on the basis of widespread use.

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.

Why exactly do we need to see other browsers support Chacha20? That's a viewpoint I imagine is shared by zero working crypto engineers; am I wrong?

They can, if they're using Chrome and the server has compiled OpenSSL from source and applied the relevant patches, linked to in the article, required for OpenSSL to support it.

Conversely, people are unlikely to be able to use chacha20 until we start encouraging its use.

Sure, but we can't encourage it's use until people can get access to server software that includes it, and openssl - and everything that links to libssl - doesn't right now.

Cloudflare implements Chacha20/Poly1305 using OpenSSL, and published their patches.

I know, that's why I linked to those patches in the article, then subsequently mentioned their existence in another response to you three hours before you wrote the above.

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.

I don't understand why a sober assessment of people's SSL implementations should account for stuff like this.

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".

Encourage people to use a library that includes chacha20...

That's pretty reasonable, if libre or boring started using it (especially since they both have other advantages over open).

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact