Perfect Forward Secrecy: Default ciphers and Chrome

[jorangreef]

I assumed that with the right OpenSSL and with default ciphers, that a connection from Chrome would negotiate using ECDHE.

The default ciphers are: ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL

But I think that with those Chrome settles for AES128-GCM-SHA256, see: https://www.ssllabs.com/ssltest/viewClient.html?name=Chrome&version=39&platform=OS%20X.

Adding ECDHE-RSA-AES128-GCM-SHA256 to the default ciphers list would fix this.

I don't know if this is an issue or not, but I think it would be great if io.js servers supported perfect forward secrecy on most major browsers out of the box.

[silverwind]

The docs state it as supported: https://iojs.org/api/tls.html#tls_perfect_forward_secrecy

Did you run your server against ssllabs's tests?

[jorangreef]

Yes, PFS is supported by io.js TLS. My point is that the default ciphers in io.js will not result in PFS with Chrome's preferences (see the ssllabs link above and compare the cipher order there).

I have tested with and without the suggested change above and before the change, Chrome is without PFS, and after it is. The reason is that Chrome goes for GCM (to do the encryption and authentication in one go rather than do the authentication separately) which the default ciphers do not yet include support for.

I was running against ssllab's tests and that's actually how I came across this. I was surprised at first, because PFS was working in Firefox but not in Chrome.

[Fishrock123]

cc @indutny?

[silverwind]

Running this config

{
    key              : "path"
    cert             : "path"
    ca               : "path"
    dhparam          : "path"
    honorCipherOrder : true
}

against ssllabs shows that Chrome indeed doesn't pick an ECDHE cipher:

Android 2.3.7                TLS 1.0  TLS_RSA_WITH_RC4_128_SHA (0x5)
Android 4.0.4                TLS 1.0  TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
Android 4.1.1                TLS 1.0  TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
Android 4.2.2                TLS 1.0  TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
Android 4.3                  TLS 1.0  TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
Android 4.4.2                TLS 1.2  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
BingBot Dec 2013             TLS 1.0  TLS_RSA_WITH_RC4_128_SHA (0x5)
BingPreview Jun 2014         TLS 1.0  TLS_RSA_WITH_RC4_128_SHA (0x5)
Chrome 39 / OS X             TLS 1.2  TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)
Firefox 31.3.0 ESR / Win 7   TLS 1.2  TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
Firefox 34 / OS X            TLS 1.2  TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
Googlebot Jun 2014           TLS 1.0  TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
IE 6 / XP                    Protocol or cipher suite mismatch
IE 7 / Vista                 TLS 1.0  TLS_RSA_WITH_RC4_128_SHA (0x5)
IE 8 / XP                    TLS 1.0  TLS_RSA_WITH_RC4_128_SHA (0x5)
IE 8-10 / Win 7              TLS 1.0  TLS_RSA_WITH_RC4_128_SHA (0x5)
IE 11 / Win 7                TLS 1.2  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
IE 11 / Win 10 Preview       TLS 1.2  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
IE 11 / Win 8.1              TLS 1.2  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
IE Mobile 10 / Win Phone 8.0 TLS 1.0  TLS_RSA_WITH_RC4_128_SHA (0x5)
IE Mobile 11 / Win Phone 8.1 TLS 1.2  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Java 6u45                    TLS 1.0  TLS_RSA_WITH_RC4_128_SHA (0x5)
Java 7u25                    TLS 1.0  TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
Java 8b132                   TLS 1.2  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
OpenSSL 0.9.8y               TLS 1.0  TLS_RSA_WITH_RC4_128_SHA (0x5)
OpenSSL 1.0.1h               TLS 1.2  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Safari 5.1.9 / OS X 10.6.8   TLS 1.0  TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
Safari 6 / iOS 6.0.1         TLS 1.2  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Safari 7 / iOS 7.1           TLS 1.2  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Safari 8 / iOS 8.0 Beta      TLS 1.2  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Safari 6.0.4 / OS X 10.8.4   TLS 1.0  TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
Safari 7 / OS X 10.9         TLS 1.2  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Yahoo Slurp Jun 2014         TLS 1.2  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
YandexBot Sep 2014           TLS 1.2  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)

[silverwind]

Removing AES128-GCM-SHA256 from the default ciphers seems to be enough to let Chrome choose TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA. Any special reason to keep that cipher?

[silverwind]

@jorangreef did you by chance test with honorCipherOrder enabled? My tests show that Chrome negotiates ECDHE fine without it, but with it set, I get the RSA cipher as seen above.

[jorangreef]

@silverwind Yes, well spotted. I was testing with honorCipherOrder enabled, and I also get ECDHE on Chrome with that disabled.

honorCipherOrder forces Chrome to pick AES128-GCM-SHA256 over the cipher including ECDHE that it would pick through HIGH.

Swapping AES128-GCM-SHA256 with HIGH in the default ciphers, i.e. ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:HIGH:AES128-GCM-SHA256:RC4:!MD5:!aNULL would lead to ECDHE on Chrome even with honorCipherOrder enabled.

But AES128-GCM-SHA256 is very good and should be in the default ciphers. The real problem is that we don't have enough ECDHE options coming through in ECDHE-RSA-AES128-SHA256.

Adding ECDHE-RSA-AES128-GCM-SHA256 would do the trick.

[silverwind]

In the PR, I've been suggested this explicit list: https://gist.github.com/indutny/344b7ebd245068ffd1d6 , it lists AES128-GCM-SHA256 pretty low, so I think it should solve the issue as well.

There're quite a few options we have on improving the cipher list and it seems there's no universally accepted 'secure' list. I'll test more later.

[bnoordhuis]

Out of curiosity, has anyone checked what the size of the handshake packet is before and after?

[jorangreef]

@silverwind I checked Fedor's explicit ciphers list and it's good, it just does not yet get FS with ssllab's tests for Safari and modern IE which are reference browsers:

https://www.ssllabs.com/ssltest/viewClient.html?name=Safari&version=8&platform=iOS%208.0%20Beta
https://www.ssllabs.com/ssltest/viewClient.html?name=Safari&version=6&platform=iOS%206.0.1
https://www.ssllabs.com/ssltest/viewClient.html?name=IE&version=11&platform=Win%207
https://www.ssllabs.com/ssltest/viewClient.html?name=IE%20Mobile&version=11&platform=Win%20Phone%208.1

@bnoordhuis Do you mean for all combinations of cipher negotiations and using explicit ciphers vs the default? I haven't checked but if it's just for adding ECDHE-RSA-AES128-GCM-SHA256 to the defaults (for A+ on ssllabs with honorCipherOrder enabled and removing RC4) then surely there would be no change as that cipher just uses GCM compared to ECDHE-RSA-AES128-SHA256? I guess one would really have to check.

[indutny]

@jorangreef your ssllabs results contain RC4 ciphers, which my cipher list does not really have. Are you sure you was using the right configuration?

[indutny]

Aaaah... Gosh, it was a support list. Sorry.

[indutny]

@jorangreef it is rather odd that it doesn't select PFS ciphers for you. This is a test of this ciphers list on my blog: https://www.ssllabs.com/ssltest/analyze.html?d=blog.indutny.com (ignore the B grade, it is some weird bud bug).