tls: more secure defaults by silverwind · Pull Request #826 · nodejs/node

silverwind · 2015-02-12T21:19:24Z

This changes the TLS defaults to be more secure. It includes these changes:

Remove the AES128-GCM-SHA256 cipherset. It seems Chrome likes to choose it over an more secure ECDHE variant with honorCipherOrder enabled.
Disable the insecure RC4 algorithm completely. This doesn't seem to cause any new incompatibilties with clients, as IE6 can't handshake with the current defaults right now.
Enable honorCipherOrder by default. This probably should've been the default for a while now.

Combined with DH parameters > 1024 bit and HSTS, this gives an A+ rating on the OpenSSL test (was an B rating before). All clients except IE on Windows XP achieve Forward Secrecy.

Motivating issue: #818
CC: @indutny

Ciphers before this change:

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_AES_256_CBC_SHA (0xc014) Android 4.1.1 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Android 4.2.2 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Android 4.3 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Android 4.4.2 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
BingBot Dec 2013 TLS 1.0 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) BingPreview Jun 2014 TLS 1.0 TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)
Chrome 39 / OS X TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Firefox 31.3.0 ESR / Win 7 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Firefox 34 / OS X TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
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_AES_128_CBC_SHA (0x2f)
IE 8 / XP TLS 1.0 TLS_RSA_WITH_RC4_128_SHA (0x5)
IE 8-10 / Win 7 TLS 1.0 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
IE 11 / Win 7 TLS 1.2 TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)
IE 11 / Win 10 Preview TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
IE 11 / Win 8.1 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
IE Mobile 10 / Win Phone 8.0 TLS 1.0 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) IE Mobile 11 / Win Phone 8.1 TLS 1.2 TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)
Java 6u45 TLS 1.0 TLS_RSA_WITH_RC4_128_SHA (0x5)
Java 7u25 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Java 8b132 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
OpenSSL 0.9.8y TLS 1.0 TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)
OpenSSL 1.0.1h TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
Safari 5.1.9 / OS X 10.6.8 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Safari 6 / iOS 6.0.1 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
Safari 7 / iOS 7.1 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
Safari 8 / iOS 8.0 Beta TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
Safari 6.0.4 / OS X 10.8.4 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Safari 7 / OS X 10.9 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
Yahoo Slurp Jun 2014 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
YandexBot Sep 2014 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)

Ciphers after this change:

Android 2.3.7 TLS 1.0 TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) Android 4.0.4 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Android 4.1.1 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Android 4.2.2 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Android 4.3 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Android 4.4.2 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) BingBot Dec 2013 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) BingPreview Jun 2014 TLS 1.0 TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) Chrome 39 / OS X TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Firefox 31.3.0 ESR / Win 7 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Firefox 34 / OS X TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Googlebot Jun 2014 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) IE 6 / XP Protocol or cipher suite mismatch
IE 7 / Vista TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) IE 8 / XP TLS 1.0 TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)
IE 8-10 / Win 7 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) 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_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) 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_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) Java 7u25 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Java 8b132 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) OpenSSL 0.9.8y TLS 1.0 TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) 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_AES_256_CBC_SHA (0xc014) 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_AES_256_CBC_SHA (0xc014) 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)

Haven't touched the docs yet (and I probably need some assistance on these), as I'd like to get some feedback on this first.

indutny · 2015-02-12T21:38:40Z

I have a suggestion https://gist.github.com/indutny/344b7ebd245068ffd1d6 ;)

Though, maybe without AES128-GCM-SHA256 if it breaks stuff. cc @bnoordhuis

Is that list one of those well-tested-and-battle-proven ones? I have a similar long one ready here, but I think it breaks handshakes on some clients: https://gist.github.com/silverwind/8331aae19f57878fabd1

Anyways, I'll run a few more test tomorrow if we can get even better results!

Though, maybe without AES128-GCM-SHA256 if it breaks stuff.
Maybe not outright break as in handshake failures but I imagine it's possible that without AES128-GCM-SHA256, the connection gets downgraded to a TLS 1.0 cipher when the other end doesn't speak ECDH(E) or DHE.

Let's use my list @bnoordhuis ;)

The bug of load balancers due to the size of CLIENT_HELLO can be resolved by using SSL_OP_TLSEXT_PADDING options. We are no longer worrying about the size of cipher list.
In order to get A+ score from SSL Labs Server Test, the cipher list needs https://gist.github.com/shigeki/986c53242f5bd3d78609#file-server-js-L19

@shigeki that list you linked seems pretty old and includes EECDH chiphers. I'm not familiar with those, and @indutny's list doesn't include them either. Is there any benefit to them over ECDHE?

@silentrob Oh, it's a synonym. https://github.com/openssl/openssl/blob/master/ssl/ssl_locl.h#L307-L310 . ECDHE is popular and better now.

@shigeki The discussion got split a bit here. see #818 (comment) for my latest test with Fedor's list.

silverwind · 2015-02-12T22:13:50Z

Here's the list from the previous issue. Default config, but honorCipherOrder enabled. Notice Chrome choosing TLS_RSA_WITH_AES_128_GCM_SHA256:

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 · 2015-02-13T11:34:36Z

Updated the PR with @indutny's list. Here are the results with it: https://gist.github.com/silverwind/db82299eff01b1c6a200

If we agree on using this, I'll start on the docs update.

silverwind · 2015-02-13T12:38:36Z

Could probably use a template string here. Edit, oh, and it's missing :, will fix.

silverwind · 2015-02-13T12:49:08Z

Some more cipher discussion here: #818

silverwind · 2015-02-13T13:42:29Z

Regarding docs, I think it's worthwile to mention that IE6 can't handshake with the defaults, maybe we should provide an alternate ultra-compatible cipher set in the docs for these cases.

silverwind · 2015-02-13T18:21:54Z

Docs done. Removed lot of cruft and a ugly TODO.

Please review, @indutny @bnoordhuis

indutny · 2015-02-13T18:25:40Z

LGTM

silverwind · 2015-02-13T18:34:28Z

squashed

silverwind · 2015-02-13T20:20:19Z

Hold on a sec, I just tested again with fresh build, and I get an A- score now, with a few browsers getting no FS, I suspect honorCipherOrder might not apply.

silverwind · 2015-02-13T21:10:44Z

Apparently its because IE 8 / XP gets no FS and we don't have any CBC ciphers enabled, which it would need for FS (but just with DSA key). It's pretty questionable why they include it in their score, when the browser is effectively uncapable of FS.

Anyways, I think the list is fine as is, and the score problem will eventually vanish by itself once IE8 loses reference browser status. I also verified that honorCipherOrder was intact.

jorangreef · 2015-02-14T08:47:18Z

It's also "IE Mobile 11 / Win Phone 8.1" and "IE 11 / Win 7" which are not getting FS with those latest ciphers in the pull request.

Also latest versions of Safari are only getting FS on DHE whereas they should be getting FS on ECDHE:

Safari 8 / iOS 8.0 Beta R TLS 1.2 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
Safari 7 / OS X 10.9 R TLS 1.2 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b)

The default ciphers should definitely be using ECDHE on all the reference browsers.

silverwind · 2015-02-14T09:55:10Z

@jorangreef your results differ from mine once again. I get the same as in the gist linked earlier (https://gist.github.com/silverwind/db82299eff01b1c6a200), except the score being lowered to A-. You sure that you have the ciphers, honorCipherOrder, and dhparam?

silverwind · 2015-02-14T10:14:05Z

@jorangreef hmm, you may actually be right, it seems to have to do with cipher ordering. A simple reordering might suffice I think. Something like this?

ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA256
ECDHE-ECDSA-AES256-SHA256
ECDHE-RSA-AES256-SHA256
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-SHA256
ECDHE-RSA-AES128-SHA256
ECDHE-ECDSA-AES128-SHA
ECDHE-RSA-AES128-SHA
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-GCM-SHA256
DHE-RSA-AES256-SHA256
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-SHA256
DHE-RSA-AES128-SHA
AES256-GCM-SHA384
AES256-SHA256
AES128-GCM-SHA256
AES128-SHA256
AES128-SHA
DES-CBC3-SHA

indutny · 2015-02-14T10:15:30Z

@silverwind there is no point in preferring ECDHE over DHE. I'd better be using AES256 with DHE, than AES128 with ECDHE.

silverwind · 2015-02-14T10:17:51Z

@indutny what about these:

AES256-GCM-SHA384
AES256-SHA256

your list has them ranked pretty high, and it seems some browsers get them over a FS cipher.

silverwind · 2015-02-14T10:19:57Z

Maybe this ranking is better? https://gist.github.com/silverwind/714bcbf65bf1eb10204c

jorangreef · 2015-02-14T10:27:07Z

@silverwind, I used https://gist.github.com/jorangreef/1aa7ec6ccd82585090bc which has the latest ciphers in your pull request and honorCipherOrder enabled. It doesn't get FS in the reference browsers. Also it only gets DHE for Safari where it should definitely be getting ECDHE.

indutny · 2015-02-14T10:27:09Z

@silverwind these are the best ciphers without FS, are they selected when the browser did support FS?

indutny · 2015-02-14T10:27:42Z

@jorangreef are you sure you are not using node.js 0.10? It is the only version that didn't have ECDHE support.

jorangreef · 2015-02-14T10:29:03Z

@indutny quite sure ;)

iojs --version gives v1.2.1

Also if I was using Node 0.10 I wouldn't be getting ECDHE for most of the reference browsers (only DHE for Safari).

silverwind · 2015-02-14T10:31:24Z

are they selected when the browser did support FS?

Yes, it was IE11 and some Safari version that got them over a DHE/ECDHE as in @jorangreef's comment above.

jorangreef · 2015-02-14T10:34:36Z

I think a better testing methodology would be:

Start with Fedor's explicit ciphers list but with no DHE for starters (we add these back later once we get ECDHE on all the reference browsers).
Keep adding minimum ciphers necessary for reference browsers which don't get FS at first (using the ssllabs support pages to see the preference order for each browser and what ciphers we are missing... probably an explicit CBC).
When we get an A+ on ssllabs, add back the DHE ciphers in the right preference order and test again making sure we're still using ECDHE for the reference browsers.

All of this needs to have honorCipherOrder enabled obviously.

indutny · 2015-02-14T10:36:09Z

@jorangreef I still don't quite get why I have FS with all reference browsers here: https://www.ssllabs.com/ssltest/analyze.html?d=blog.indutny.com

silverwind · 2015-02-15T17:37:50Z

Updated, test change split out into #853

This updates the default cipher suite to an more secure list, which prefers strong ciphers with Forward Secrecy. Additionally, it enables `honorCipherOrder` by default. Noteable effect of this change is that the insecure RC4 ciphers are disabled and that Chrome negotiates a more secure ECDHE cipher.

silverwind · 2015-02-15T17:45:26Z

Fixed two more spellings in the docs ('ciphersuite' -> 'cipher suite')

bnoordhuis · 2015-02-15T17:45:37Z

Still LGTM. I'll leave it to @indutny to sign off on it and land it.

This updates the default cipher suite to an more secure list, which prefers strong ciphers with Forward Secrecy. Additionally, it enables `honorCipherOrder` by default. Noteable effect of this change is that the insecure RC4 ciphers are disabled and that Chrome negotiates a more secure ECDHE cipher. Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Fedor Indutny <fedor@indutny.com> PR-URL: #826

indutny · 2015-02-16T11:33:51Z

@silverwind Landed in 77f3586, thank you! Please run make test next time, there was some minor failures and jslint errors.

Notable changes: * url: `url.resolve('/path/to/file', '.')` now returns `/path/to/` with the trailing slash, `url.resolve('/', '.')` returns `/`. #278 (Amir Saboury) * tls: tls (and in turn https) now rely on a stronger default cipher suite which excludes the RC4 cipher. If you still want to use RC4, you have to specify your own ciphers suite. #826 (Roman Reiss)

Port of io.js commit: nodejs/node@77f3586 Original commit message: This updates the default cipher suite to an more secure list, which prefers strong ciphers with Forward Secrecy. Additionally, it enables `honorCipherOrder` by default. Noteable effect of this change is that the insecure RC4 ciphers are disabled and that Chrome negotiates a more secure ECDHE cipher. Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Fedor Indutny <fedor@indutny.com> PR-URL: nodejs/node#826

Restuta · 2015-05-08T17:25:11Z

I am writing some web-scrapers that have to support not-so cool and secure web-sites that still use legacy ciphers. What is the right way to override defaults and say "yes, use RC4!"?

silverwind · 2015-05-08T17:32:01Z

@Restuta Set the ciphers option to a string like this. It's mentioned in the docs.

ciphers: "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA"

Restuta · 2015-05-08T17:39:28Z

@silverwind yeah, I read this, but I am struggling to make request work with this. It internally uses https module.

Restuta · 2015-05-08T17:40:39Z

it would be nice to have like a node flag --use-legacy-ciphers that globally overrides defaults, so we don't have to figure it out for every lib that uses https internally

bnoordhuis · 2015-05-08T17:43:37Z

You could do that through a pre-load (-r) module. I'm personally -1 on a flag. If people want insecure defaults, it's okay to make them jump through a few hoops; maybe it makes them reconsider.

silverwind · 2015-05-08T17:45:52Z

@Restuta It's quite possible that request specifies a custom cipher suite, which would override such a flag. Also, i'd say, this is more of a feature request to request, because ultimately, they are in control of the ciphers, io.js just provides extendable defaults.

silverwind · 2015-05-08T18:04:01Z

@Restuta For request, you should be able to specify ciphers in agentOptions.

Restuta · 2015-05-08T18:04:09Z

@bnoordhuis web-scraping is a good example, what could you possible reconsider there? Point is that some use-cases are valid and make that subset of people suffer so superset of people don't have an easy option to use insecure defaults and therefore less likely will use it is hard to justify. To me it's not very obvious decision.

@silverwind looks like. Mb web-scraping is very specific case and there are not that many libs like request, so it's okay. Thanks for the quick response.

Just found a way to do it with request:

var options = {
url: 'https://www.usacycling.org,
agentOptions: {
ciphers: '<here you go>',
}
};
//and then //request(options, ....

or set it globally:

request = require('request').defaults({
agentOptions: {
ciphers: '<here you go>',
}
})

bnoordhuis · 2015-05-08T18:16:21Z

web-scraping is a good example, what could you possible reconsider there? Point is that some use-cases are valid and make that subset of people suffer so superset of people don't have an easy option to use insecure defaults and therefore less likely will use it is hard to justify.

That's my point and I think it's very easy to justify. The people motivated enough will jump through the required hoops, whereas the quick hack crowd, people who would add the flag and move on without giving it a second thought, will now hopefully stop to consider the ramifications.

Restuta · 2015-05-08T18:26:35Z

@bnoordhuis to me something in the middle is more appealing. Like a big warning after you specified a flag saying that you just killed a baby unicorn (with an optional picture and your github avatar updated). So if you are desperate enough to read the docs, set this flag up, ignore the warning – you deserve all the consequences =)

indutny reviewed Feb 12, 2015
View reviewed changes

silverwind changed the title ~~tls - more secure defaults~~tls: more secure defaultsFeb 13, 2015

silverwind force-pushed the better-tls-defaults branch from 5627f4c to b240065Compare February 13, 2015 11:31

silverwind reviewed Feb 13, 2015
View reviewed changes

silverwind force-pushed the better-tls-defaults branch from b240065 to 913a17cCompare February 13, 2015 12:45

silverwind mentioned this pull request Feb 13, 2015
Perfect Forward Secrecy: Default ciphers and Chrome #818
Closed

silverwind force-pushed the better-tls-defaults branch from 199b81f to cc10f5dCompare February 13, 2015 18:33

silverwind force-pushed the better-tls-defaults branch from 22c0783 to cbb369cCompare February 15, 2015 17:44

indutny closed this Feb 16, 2015

rvagg mentioned this pull request Feb 18, 2015
Release proposal: v1.3.0 #872
Closed

bnb mentioned this pull request Feb 20, 2015
Evangelism: Weekly Update Feb 20th nodejs/iojs.org#188
Closed

clonn mentioned this pull request Feb 21, 2015
translate io.js Week of February 20th 2015 nodejs/nodejs-zh-TW#46
Merged

dahjelle mentioned this pull request Feb 26, 2015
Node.js sample configurations? mozilla/server-side-tls#20
Closed

jasnell mentioned this pull request Mar 31, 2015
tls: more secure defaults nodejs/node-v0.x-archive#14194
Closed

surdu mentioned this pull request Feb 29, 2016
Illegal instruction on ARM Linux (raspberry pi) #5495
Closed

solebox mentioned this pull request May 13, 2022
[Snyk] Fix for 1 vulnerabilities solebox/node#29
Open

enterstudio mentioned this pull request May 14, 2022
[Snyk] Fix for 1 vulnerabilities enterstudio/node#28
Open

s4sc mentioned this pull request May 14, 2022
[Snyk] Fix for 1 vulnerabilities s4sc/node#28
Open

Uh oh!

Uh oh!

Conversation

silverwind commented Feb 12, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

silverwind commented Feb 12, 2015

Uh oh!

silverwind commented Feb 13, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

silverwind commented Feb 13, 2015

Uh oh!

silverwind commented Feb 13, 2015

Uh oh!

silverwind commented Feb 13, 2015

Uh oh!

indutny commented Feb 13, 2015

Uh oh!

silverwind commented Feb 13, 2015

Uh oh!

silverwind commented Feb 13, 2015

Uh oh!

silverwind commented Feb 13, 2015

Uh oh!

jorangreef commented Feb 14, 2015

Uh oh!

silverwind commented Feb 14, 2015

Uh oh!

silverwind commented Feb 14, 2015

Uh oh!

indutny commented Feb 14, 2015

Uh oh!

silverwind commented Feb 14, 2015

Uh oh!

silverwind commented Feb 14, 2015

Uh oh!

jorangreef commented Feb 14, 2015

Uh oh!

indutny commented Feb 14, 2015

Uh oh!

indutny commented Feb 14, 2015

Uh oh!

jorangreef commented Feb 14, 2015

Uh oh!

silverwind commented Feb 14, 2015

Uh oh!

jorangreef commented Feb 14, 2015

Uh oh!

indutny commented Feb 14, 2015

Uh oh!

silverwind commented Feb 15, 2015

Uh oh!

silverwind commented Feb 15, 2015

Uh oh!

bnoordhuis commented Feb 15, 2015

Uh oh!

indutny commented Feb 16, 2015

Uh oh!

Restuta commented May 8, 2015