Usage of insecure curves still common
This article continues my research from 2015 which you should read to get an impression of some nasty "the-NSA-backdoored-our-crypto" things.
Findings from 2015 in a nutshell
In 2015 I checked some browsers and recommendations for webserver configuration and the support of "trustworthy" cryptography when using forward secrecy with elliptic curves.
It turned out that all major browsers, Chrome, Firefox, Edge, Internet Explorer, and Opera only supported questionable (i.e. "defined-by-NIST-probably-backdoored-by-NSA") cryptographic parameters (secp256r1, secp384r1, secp521r1) whenever forward secrecy using elliptic curves (i.e. ECDHE) had to be in place. At the same time many institutions (e.g. Qualys, Mozilla, IETF, and Acunetix) recommended you to activate forward secrecy using elliptic curves.
The finding was, that most confidential communication on the Internet used suspicious cryptographic parameters. Trustworthy alternatives (e.g. using Curve25519) for elliptic cryptography were not available at all. Neither in the browser, nor on the webserver side.
What has changed in the past two years?
Some time after my last blog post I found that browser vendors wanted to implement support for X25519 to provide an alternative to the fishy NIST curves. Some more time has passed now and so I wanted to check the progress, and if X25519 is indeed used in our daily business by default.
In this article I would like to show you my findings.
Browser support for X25519? Yes!
Most browser vendors have added support for Curve25519. That's good news! Chrome, Firefox, Opera and Edge support it, IE11 does not. Where supported X25519 is even on top of the browser's preference list. That's also good news, but keep reading ...
So far so good. At least things changed in the browser world.
(I will leave IE11 out for the rest of this article - no news for this one anyway)
Server support for X25519? Meeeeh...!
It needs two for this game. The best browser cannot speak freely when the bad server doesn't want them to...
How about ... PayPal?
I usually choose PayPal to dump traffic. PayPal, because they usually do things right and serve as a good reference. Not in this case, however:
O PayPal, Where Art Thou?
Though the browser supports X25519 but the server does not and so secp256r1 is chosen for key agreement 😒
That is not too promising at all. I wonder how other servers handle those requests for X25519. Let's check that!
How about ... Google?
Good ol' Goo'!
Google - X25519 - good!
How about ... Alexa Top 100?
Of course, I wrote a scanner to check Alexa Top X sites for their curve usage. I checked three things
- Does the site support x25519?
- Does the site prefer x25519?
- Does the site honor the client's curve preference for x25519?
(2) is checked by sending ECDHE as the only supported cipher suites and "P-256:X25519" as the only supported curves, in that order. "Good" servers should choose X25519 even if it is only the client's second preference.
(This point is a bit tricky, because you can also say that "good" servers should honor the client's preference. I acknowledge that argument but in terms of security the trustworthy curves should always win if the client supports them.)
(3) is checked by sending ECDHE as the only supported cipher suites and "X25519:P-256" as the only supported curves, in that order. "Good" servers should choose X25519, i.e. the client's preference, even though they have the choice to use P-256.
Now servers can either not support X25519 at all, or have one of the following combinations:
Prefers X25519: Yes, Honors client's prefs: Yes
("x25519 preferred") These servers choose X25519, no matter what the client says. They use their own preferences and X25519 is on top. Good.
Prefers X25519: Yes, Honors client's prefs: No
These servers choose X25519 unless the client prefers X25519 in which case they choose P-256. That's weird - and is an indication that there is some load balancing going on where the servers are configured differently, some good, some bad.
Prefers X25519: No, Honors client's prefs: Yes
("Client's choice") These servers select the curve that the client prefers. Even if X25519 is supported, the server chooses P-256 when the client prefers that. This is arguably bad behavior, at least from a security perspective. These servers should be changed to use X25519 when the client supports it.
Prefers X25519: No, Honors client's prefs: No
("P-256 preferred") That's a bad combination, and a big NO-NO-NO-NO-NO! Although these servers support X25519 they virtually never use it. Again you may find this combination due to load balancing issues, but it is usually an indication that a server has been configured to use their own curve preferences and P-256 is on top of it. The bad thing is that this guy looks friendly - it supports X25519 - but has a bad-ass behavior - it never uses X25519 in real life. (e.g. www.microsoft.com ^^)
However, the solution is easy, change the curve preferences to have X25519 on top and everything is fine :-)
This is how the Alexa Top 100 sites look in terms of X25519:
 |
| Alexa Top 100 - X25519 Support |
And here are the Alexa Top 10k results:
 |
| Alexa Top 10.000 - X25519 Support |
You can download the
- Alexa Top 10k results here and
- the whole Alexa Top 1 million results here.
Conclusion
From the Top 100 websites only 38 provide sensible configuration. When I started this article I expected to see X25519 being in use virtually everywhere. It may take some more time to fix things, but the missing Top 62 sites should definitely hurry up, especially the 57 which do not support X25519 at all!
Given the Top 10k websites things look even worse. About 70% do not even support X25519 and only ~8.7% come with a sensible configuration, while 5.2% would not use X25519 even if the client requested its use.
Also ...
If you looked carefully at the screenshots above, you may have noticed that even though "good" servers use X25519 for key agreement, they still stick to secp256r1 for signatures. A standard for signing with Curve25519 left the draft status only in January 2018.
You may also have noticed "GREASE" in the screenshots above. These are random values used for testing TLS implementations for compatibility problems on-the-fly. This mechanism has been invented by a google engineer to test servers if they ignore unknown values as they should.
Conclusion in a nutshell
Tips & Tricks
If you want to scan a few servers, you can use the OpenSSL (> v1.1.0) command line client:
$ openssl version OpenSSL 1.1.0g 2 Nov 2017 $ # Check 1: X25519 support $ echo|openssl s_client -connect www.microsoft.com:443 -cipher ECDHE -curves "X25519" 2>&1 | grep "Server Temp Key" Server Temp Key: X25519, 253 bits $ # Check 2: X25519 preferrence $ echo|openssl s_client -connect www.microsoft.com:443 -cipher ECDHE -curves "P-256:X25519" 2>&1 | grep "Server Temp Key" Server Temp Key: ECDH, P-256, 256 bits $ # Check 3: use client's preference $ echo|openssl s_client -connect www.microsoft.com:443 -cipher ECDHE -curves "X25519:P-256" 2>&1 | grep "Server Temp Key" Server Temp Key: ECDH, P-256, 256 bits
