
Why your 'A' grade SSL is 'outdated cryptography' on Chrome - nailer
https://certsimple.com/blog/chrome-outdated-cryptography
======
ivanr
(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?

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

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

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

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

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

~~~
agwa
Indeed.

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.

------
realusername
I don't know if it's planned with the lets-encrypt tool but these things
should be really be done automatically. It feels a bit like downloading
manually .tar.gz files to do system updates instead of a standard update tool.
A system update should update the list of recommended ciphers for OpenSSL and
the webserver should just grab the list from OpenSSL directly, there should
not be any need to modify any configuration file. It's really exhausting to
keep-up with the current state of ciphers all the time. People are pointing
out the cost of certificates but in reality, the complexity of all of this is
the real barrier, it's far more complex than it should be.

~~~
derefr
Another way to think about it: if there's a use-case where the API OpenSSL
provides (requiring that the consumer specify a list of cipher-suites, etc.)
is wrong, then that consumer should not be directly consuming OpenSSL; that
level of abstraction is the wrong fit for their project.

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.

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

The idea of a library to implement that logic is solid: we made
[https://www.npmjs.com/package/ssl-rsa-
strength](https://www.npmjs.com/package/ssl-rsa-strength) as a library
implementing Mozilla's logic a little while ago.

------
brohoolio
I appreciate Google being aggressive in this front, but they've trained
people, like my mom, to ignore the little green lock in the last 6 months.

~~~
bm98
It's worse than that. They've trained users to ignore the RED "X" on the
little lock and the RED strikethrough on the "https" that Chrome shows for
sites with SHA1-signed certs that expire after 2016[1]. Reasonable or not,
some sites can't or won't update their certs and have no choice but to tell
Chrome users to ignore those warnings.

[1]
[http://googleonlinesecurity.blogspot.com/2014/09/gradually-s...](http://googleonlinesecurity.blogspot.com/2014/09/gradually-
sunsetting-sha-1.html)

~~~
sp332
You don't have to ignore the warning. It means that what you see on the site
_might_ have been recorded or modified in transit, and what you type in
_might_ be recorded or modified on the way back to the server. You might
decide that it's fine for browsing but decline to put in personal information
on those sites. It's up to you.

~~~
akerl_
The problem is that outside of our niche of people who really care about tech,
most people just care about the contents of the webpages they visit. They
aren't reading/understanding the warning and have no context for making that
assessment of safety and responding appropriately. They just know that they
want to go to their bank's site or play the latest Mafiaville or whatever.

These changes in Chrome are teaching them that the red marks on the location
bar are just a normal part of those interactions.

------
ivanr
For completeness, also be aware that it's possible to get (yellow and red)
warnings in Chrome even if you're serving a full SHA2 certificate chain and
have the best possible configuration otherwise. Apparently, this is because
Chrome outsources certificate chain construction and validation (different
library depending on the underlying operating system), and they sometimes
create SHA1 paths even when better paths are valid.

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.

~~~
agwa
Indeed. Debian is one OS which is affected by this, because they shipped an
outdated version of NSS (the crypto library used by Chrome) which does the
suboptimal path generation.

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](https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=774195)

------
tptacek
It really _shouldn 't_ be possible to get an SSL Labs 'A' with anything but
GCM or Poly1305.

~~~
tomjen3
Doesn't that mean giving up old browsers though?

~~~
tptacek
Are you the kind of person who sees a 'B' as a failing grade?

~~~
tomjen3
If getting an A requires things that are, for a large portion, not feasable
then I consider that a failing grade, but it is the test that fails, not me.

Anyway I asked a factual question, I would like an answer.

~~~
tptacek
The answer is "no".

------
madaxe_again
Our "C" rated SSL is "modern cryptography" on Chrome - because we offer
ECDHE_RSA/AES_128_GCM - but because we also offer RC4, because eCommerce, and
bloody winXP users still existing, and still being a source of revenue. They
do win a "UPGRADE YOUR BROWSER, SUCKER, YOU ARE INSECURE!" banner, but we will
have to keep RC4 available for as long as Windows XP continues to provide >1%
of our clients' revenue.

~~~
Daneel_
You don't need to use RC4 to support windows xp with IE8 - you can even get
away with using TLS1.0 and above. If you need to support IE6 though, then
yeah, you're stuck :/

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.

SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA128:DHE-
RSA-AES128-GCM-SHA384:DHE-RSA-AES128-GCM-SHA128:ECDHE-RSA-AES128-SHA384:ECDHE-
RSA-AES128-SHA128:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-
AES128-SHA128:DHE-RSA-AES128-SHA128:DHE-RSA-AES128-SHA:DHE-RSA-
AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-
SHA384:AES128-GCM-
SHA128:AES128-SHA128:AES128-SHA128:AES128-SHA:AES128-SHA:DES-
CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4 SSLProtocol All -SSLv2
-SSLv3 SSLHonorCipherOrder On

------
lemming
Seriously, SSL is such a mess. I dutifully switched my product's website to
SSL a year or so ago, and I can't count the amount of time I've spent trying
to optimise my SSL settings, and trying to figure out what optimising them
even means. I'm pretty technical, but like trying to run a correctly
configured mail server, this is just too hard. So I end up not worrying about
my grade and probably end up using old, obsolete encryption because of it.

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.

~~~
ibejoeb
I've had a lot of good experiences lately using SSLMate
([https://sslmate.com/](https://sslmate.com/)) to automatically buy, download,
generate chains, and renew certificates.

Then, I use Mozilla's SSL configuration generator
([https://mozilla.github.io/server-side-tls/ssl-config-
generat...](https://mozilla.github.io/server-side-tls/ssl-config-generator/))
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.

------
eterm
This area is a mess, there is now a difference between all major browsers and
even between Firefox versions (With the Developer version complaining where
regular FF does not).

For example firefox mentions SHA-1 insecurity when visting the google jquery
CDN. [1] Chrome doesn't seem to care however and there are other sites where
it is vice-versa.

[1]
[https://ajax.googleapis.com/ajax/libs/jquery/2.1.3/jquery.mi...](https://ajax.googleapis.com/ajax/libs/jquery/2.1.3/jquery.min.js)

~~~
illumin8
It's frustrating that Chrome and Firefox don't give any details about why the
connection to an insecure site fails. You just get a "connection reset" page
in Chrome, and a generic SSL security error in Firefox.

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.

~~~
cbhl
> _And, please give advanced users a way to click through anyway._

This already exists, and you can find it by reading through the source of
Chromium.

------
nailer
Author here. This actually came from a real case: it was fairly surprising the
SSL Labs test wasn't flagging the ciphers that cause the 'outdated
cryptography' warning.

~~~
davewongillies
Thanks for this blog post. I was attempting to fix up a server last week and
couldn't find or figure out a fix for it at the time.

~~~
yugcesofni
I think this is the experience of a lot of people and good security folks are
taking notice to try and help: [https://blog.digicert.com/understanding-the-
google-chrome-co...](https://blog.digicert.com/understanding-the-google-
chrome-connection-tab/)

------
Daneel_
I'd recommend checking out [https://cipherli.st](https://cipherli.st) for
practical information on ciphers. It's quite easy to achieve an A+ by
following their recommendations, once you understand the impact some of the
changes might have (eg, using HSTS).

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.

------
spiritplumber
Reminds me of a trick used by creationist high school textbooks.

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

------
this_user
While we are on the topic of A-grade security: The article might want to point
out that using standard DHE is preferable to ECDHE if you can handle the
additional CPU load. The problem with ECDHE is that all currently TLS-approved
curves need to be considered unreliable. This will change if 'draft-irtf-cfrg-
curves-02' is accepted and Curve25519 and Ed448-Goldilocks become part of the
standard.

~~~
akerl_
Can you clarify why the TLS-approved curves should be considered unreliable?

~~~
tedunangst
Mumble mumble NIST mumble.

~~~
akerl_
That's the problem with tinfoil; no matter how much I wrap around my computer,
I can never be sure if the government has suborned my local grocery store.

------
baby
Very informative but not very educational. I had much more pleasure reading
what they referenced:
[https://wiki.mozilla.org/Security/Server_Side_TLS](https://wiki.mozilla.org/Security/Server_Side_TLS)

------
slyall
Reading this article and the comments here I'm stuck by how complicated (at
least non trivial) the whole thing is.

At the same time we are trying to push every website (including blogs, little-
league clubs, joke sites) to https-only.

------
rasz_pl
Secure connection: fatal error (40) from server.

ECDHE or gtfo :(

------
teddyh
I recommend <[https://bettercrypto.org/>](https://bettercrypto.org/>).

------
commentnull
Chrome changing the rules again? Unpossible! Still, the good news is that
people are leaving chrome for ff, safari, new ie, so soon, it will be less of
a problem. Hurrah!

~~~
Dylan16807
You don't think forward secrecy is critical to secure communication? I'd rank
it as more important than the SHA1 weakness problems.

