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)

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.

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

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 honorCipherOrder might not apply.

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.

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.

@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?

@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

@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:

AES256-GCM-SHA384
AES256-SHA256

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

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.

I think a better testing methodology would be:

1. 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).
2. 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).
3. 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.

@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

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.

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

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

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

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

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.

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

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

@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>',
  }
})

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.

@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 =)