tls: more secure defaults #826
Conversation
| @@ -15,9 +15,9 @@ exports.SLAB_BUFFER_SIZE = 10 * 1024 * 1024; | |||
|
|
|||
| exports.DEFAULT_CIPHERS = | |||
| // TLS 1.2 | |||
| 'ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:AES128-GCM-SHA256:' + | |||
| 'ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:' + | |||
There was a problem hiding this comment.
I have a suggestion https://gist.github.com/indutny/344b7ebd245068ffd1d6 ;)
There was a problem hiding this comment.
Though, maybe without AES128-GCM-SHA256 if it breaks stuff. cc @bnoordhuis
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Anyways, I'll run a few more test tomorrow if we can get even better results!
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Let's use my list @bnoordhuis ;)
There was a problem hiding this comment.
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
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
@shigeki The discussion got split a bit here. see #818 (comment) for my latest test with Fedor's list.
|
Here's the list from the previous issue. Default config, but |
silverwind
force-pushed
the
better-tls-defaults
branch
from
5627f4c to
b240065
Compare
|
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. |
| 'AES128-GCM-SHA256' + | ||
| 'AES128-SHA256' + | ||
| 'AES128-SHA' + | ||
| 'DES-CBC3-SHA'; |
There was a problem hiding this comment.
Could probably use a template string here. Edit, oh, and it's missing :, will fix.
silverwind
force-pushed
the
better-tls-defaults
branch
from
b240065 to
913a17c
Compare
|
Some more cipher discussion here: #818 |
|
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. |
|
Docs done. Removed lot of cruft and a ugly TODO. Please review, @indutny @bnoordhuis |
|
LGTM |
silverwind
force-pushed
the
better-tls-defaults
branch
from
199b81f to
cc10f5d
Compare
|
squashed |
|
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 |
|
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 |
|
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 The default ciphers should definitely be using ECDHE on all the reference browsers. |
|
@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, |
|
@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? |
|
@silverwind there is no point in preferring ECDHE over DHE. I'd better be using AES256 with DHE, than AES128 with ECDHE. |
|
@indutny what about these: your list has them ranked pretty high, and it seems some browsers get them over a FS cipher. |
|
Maybe this ranking is better? https://gist.github.com/silverwind/714bcbf65bf1eb10204c |
|
@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. |
|
@silverwind these are the best ciphers without FS, are they selected when the browser did support FS? |
|
@jorangreef are you sure you are not using node.js 0.10? It is the only version that didn't have ECDHE support. |
|
@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). |
Yes, it was IE11 and some Safari version that got them over a DHE/ECDHE as in @jorangreef's comment above. |
|
I think a better testing methodology would be:
All of this needs to have honorCipherOrder enabled obviously. |
|
@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 |
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
force-pushed
the
better-tls-defaults
branch
from
22c0783 to
cbb369c
Compare
|
Fixed two more spellings in the docs ('ciphersuite' -> 'cipher suite') |
|
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 <[email protected]> Reviewed-By: Fedor Indutny <[email protected]> PR-URL: #826
|
@silverwind Landed in 77f3586, thank you! Please run |
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 <[email protected]> Reviewed-By: Fedor Indutny <[email protected]> PR-URL: nodejs/node#826
|
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!"? |
|
@Restuta Set the 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" |
|
@silverwind yeah, I read this, but I am struggling to make |
|
it would be nice to have like a node flag |
|
You could do that through a pre-load ( |
|
@Restuta It's quite possible that |
|
@Restuta For |
|
@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 Just found a way to do it with or set it globally: |
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. |
|
@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 =) |
This changes the TLS defaults to be more secure. It includes these changes:
AES128-GCM-SHA256cipherset. It seems Chrome likes to choose it over an more secure ECDHE variant withhonorCipherOrderenabled.honorCipherOrderby 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:
Ciphers after this change:
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.