5 ms·

CloudFlare's internet-facing SSL cipher configuration

56 points by FiloSottile 12y ago

latimer 12y ago
Here's Mozilla's version: https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Ciphersuite https://wiki.mozilla.org/Security/Server_Side_TLS#Recommende...
- praseodym 12y ago
  That. I really appreciate being able to read the motivation behind chosen cipher set. Furthermore, they have great config examples for nginx and others[1] -- it's pretty easy to forget/misconfigure things like Diffie-Hellman parameters, OCSP stapling and session caching. [1] https://wiki.mozilla.org/Security/Server_Side_TLS#Nginx https://wiki.mozilla.org/Security/Server_Side_TLS#Nginx
rdl 12y ago
What are the best tools for tracking this, in general, for third party sites? I tend to use the Qualys SSL Test and EFF SSL Observatory, but there have to be other/better tools.
hackerboos 12y ago
I use https://www.ssllabs.com/ssltest/ https://www.ssllabs.com/ssltest/ to get my SSL in shape. I couldn't believe how much my setup failed the first time I ran it.
joevandyk 12y ago
Shouldn't nginx default to the best cipher set?
- korzun 12y ago
  The best cipher set might not be the best for everybody.
korzun 12y ago
Can somebody explain why they are still using RC4 in their configuration? https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what https://community.qualys.com/blogs/securitylabs/2013/03/19/r...
- pfg 12y ago
  The link you provided has the answer: >The difficulty is that, for public web sites that need to support a wide user base, there is practically nothing 100% secure they can use to replace RC4. Also, given the cipher preference, RC4 wont be used with modern browsers.
- huxley 12y ago
  http://blog.cloudflare.com/killing-rc4 http://blog.cloudflare.com/killing-rc4 It's to balance the need to protect against BEAST vs RC4 issues. They use an OpenSSL patch that "disables RC4-based cipher suites for connections using TLS v1.1 and above, while leaving them there to protect users still using TLS v1.0"
sitkack 12y ago
Youtube requires RC4 for some reason, I don't understand it.
- rasz_pl 12y ago
  THIS I disabled all the broken crypto (RC4, RSA handshake) in my browser few months ago and everything was fine for a while. Then about 2-3 months ago Youtube\gmail started demanding RC4. Another "funny" example of this was oculusvr.com oculusvr.com/order/ redirects to https://www.oculusvr.com/order/ https://www.oculusvr.com/order/ requires RC4 and RSA, doesnt like diffiehelman and AES BUT https://support.oculusvr.com/home https://support.oculusvr.com/home less critical part of the site works with more secure AES/DH So the part of the site that deals with confidential data and money defaults to BROKEN crypto, while bugtracker works fine with secure crypto. W T F????
  - mnutt 12y ago
    Their support site is most likely hosted by Zendesk, who have a different configuration.
- vilda 12y ago
  sslscan --no-failed youtube.com: Supported Server Cipher(s): Accepted SSLv3 256 bits ECDHE-RSA-AES256-SHA Accepted SSLv3 256 bits AES256-SHA Accepted SSLv3 168 bits ECDHE-RSA-DES-CBC3-SHA Accepted SSLv3 168 bits DES-CBC3-SHA Accepted SSLv3 128 bits ECDHE-RSA-AES128-SHA Accepted SSLv3 128 bits AES128-SHA Accepted SSLv3 128 bits ECDHE-RSA-RC4-SHA Accepted SSLv3 128 bits RC4-SHA Accepted SSLv3 128 bits RC4-MD5 Accepted TLSv1 256 bits ECDHE-RSA-AES256-SHA Accepted TLSv1 256 bits AES256-SHA Accepted TLSv1 168 bits ECDHE-RSA-DES-CBC3-SHA Accepted TLSv1 168 bits DES-CBC3-SHA Accepted TLSv1 128 bits ECDHE-RSA-AES128-SHA Accepted TLSv1 128 bits AES128-SHA Accepted TLSv1 128 bits ECDHE-RSA-RC4-SHA Accepted TLSv1 128 bits RC4-SHA Accepted TLSv1 128 bits RC4-MD5 Prefered Server Cipher(s): SSLv3 128 bits ECDHE-RSA-RC4-SHA TLSv1 128 bits ECDHE-RSA-RC4-SHA Seems like a problem in cipher ordering?
  - 12y ago
nodesocket 12y ago
We (https://commando.io https://commando.io) use: ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"; Which results in perfect forward secrecy and an A+ rating in SSL Labs.
- poobrains 12y ago
  Is that the same as Ivan Ristic's recommendation at https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy https://community.qualys.com/blogs/securitylabs/2013/08/05/c...
- edwintorok 12y ago
  Which means you shouldn't trust that A+ single metric without actually looking at the browser list or testing it yourself. I just opened your site on Debian unstable with latest Iceweasel/Firefox 24.5.0, and I get connected via RC4. Arguably thats also NSS's fault for implementing TLS1.2 so late, but still... My site only gets an "A" rating, but Firefox actually connects using ECDHE-RSA-AES256-SHA. I use this cipherlist HIGH:!SSLv2:!aNULL:!3DES Which one is more secure?
  - vilda 12y ago
    The difference between A and A+ is in Strict-Transport-Security HTTP header.
tedivm 12y ago
Anyone else remember back in 2012 when CloudFlare promised to open source their intermediary chain information? >Going forward, in addition to releasing the directory of intermediate SSL certificates on Github, we plan on releasing our SSL bundler as a free service so you can package up your SSL certificates as efficiently as possible, even if you're not using CloudFlare. Just one more way we're working to make the web fast and safe. http://blog.cloudflare.com/what-we-just-did-to-make-ssl-even-faster http://blog.cloudflare.com/what-we-just-did-to-make-ssl-even... I hate companies who lie about releasing stuff. If you look through CloudFlare's blog this isn't even the only example- they love promising to be open and give back to the community, but rarely do their actions match their words.
- korzun 12y ago
  This is pretty silly. They give back to the community and even offer free plans that are pretty damn useful. With amount of growth they have experienced, you should be thankful that they are able to find time for anything at all at this point.
- xxdesmus 12y ago
  I'll mention this internally. Thank you for the reminder (genuinely). I'll see what I can do about getting this information open sourced. [[UPDATE]] I'm hearing this is still planned, and we're aiming to get this out this coming summer. Internal projects have pushed this back a bit, apologies.
- eastdakota 12y ago
  We got distracted by other things and never got around to packaging up the packager in a way appropriate for public consumption. You will be happy to know that about a month ago we restarted that project and the team working on it is close to releasing it to the community.
- forrestthewoods 12y ago
  And comments like this are why companies hate to say anything publicly! If a company says "we plan to..." then odds are they are telling the truth. At the time of writing that is exactly what they were planning to do. It turns out that sometimes plans change. Or planned things take longer than initially planned for. But of course if you ever say anything on the internet people treat it like a promise and then you get called a liar. This is why we can't have nice things.
wzy 12y ago
How does my set up compare to the one CloudFlare and Mozilla is using ssl_ciphers ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM;
- edwintorok 12y ago
  Don't enable the MEDIUM ciphers, don't use RC4.
edwintorok 12y ago
I'm not a fan of explicitly listing cipher names: when new ciphers are added you have to revise your list again, etc. I very much prefer the simplistic approach taken by OpenSMTPD: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/smtpd/ssl.h?rev=1.7 http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/smtpd/ssl... #define SSL_CIPHERS "HIGH:!aNULL:!MD5"
- throwaway7767 12y ago
  It really bothers me that 3DES is counted in the HIGH set in OpenSSL. The HIGH set, in my mind, should include only strong ciphers that would make sense to deploy in a new product today. Otherwise, I would love to just say to the crypto library, "give me strong ciphers only".
  - kjs3 12y ago
    In what sense is 3DES not strong?
    - edwintorok 12y ago
      Its security strength is less than 2^128, doesn't mean its completely broken but there are better alternatives: https://en.wikipedia.org/wiki/Triple_DES#Security https://en.wikipedia.org/wiki/Triple_DES#Security
escapologybb 12y ago
If I have multiple VirtualHosts defined in Nginx for my two personal websites, should I define these ciphers in each file in sites-enabled or define them in the /etc/nginx/nginx.conf file? Totally realise this is a Newbie question, but I'm finding it hard to get an authoritative answer from my bumbling Googling. I really want to get this right and I thought that the hive mind here on Hacker News would be able to give me an answer that I could trust. Please downvote this if I've made a faux-hacker-pas, but be kind to the new guy! :-)

56 points by FiloSottile 12y ago

Here's Mozilla's version: https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Ciphersuite https://wiki.mozilla.org/Security/Server_Side_TLS#Recommende...

praseodym 12y ago
That. I really appreciate being able to read the motivation behind chosen cipher set. Furthermore, they have great config examples for nginx and others[1] -- it's pretty easy to forget/misconfigure things like Diffie-Hellman parameters, OCSP stapling and session caching. [1] https://wiki.mozilla.org/Security/Server_Side_TLS#Nginx https://wiki.mozilla.org/Security/Server_Side_TLS#Nginx

rdl 12y ago

What are the best tools for tracking this, in general, for third party sites? I tend to use the Qualys SSL Test and EFF SSL Observatory, but there have to be other/better tools.

hackerboos 12y ago

I use https://www.ssllabs.com/ssltest/ https://www.ssllabs.com/ssltest/ to get my SSL in shape. I couldn't believe how much my setup failed the first time I ran it.

joevandyk 12y ago

Shouldn't nginx default to the best cipher set?

korzun 12y ago
The best cipher set might not be the best for everybody.

korzun 12y ago

Can somebody explain why they are still using RC4 in their configuration? https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what https://community.qualys.com/blogs/securitylabs/2013/03/19/r...

pfg 12y ago
The link you provided has the answer: >The difficulty is that, for public web sites that need to support a wide user base, there is practically nothing 100% secure they can use to replace RC4. Also, given the cipher preference, RC4 wont be used with modern browsers.
huxley 12y ago
http://blog.cloudflare.com/killing-rc4 http://blog.cloudflare.com/killing-rc4 It's to balance the need to protect against BEAST vs RC4 issues. They use an OpenSSL patch that "disables RC4-based cipher suites for connections using TLS v1.1 and above, while leaving them there to protect users still using TLS v1.0"

sitkack 12y ago

Youtube requires RC4 for some reason, I don't understand it.

rasz_pl 12y ago
THIS I disabled all the broken crypto (RC4, RSA handshake) in my browser few months ago and everything was fine for a while. Then about 2-3 months ago Youtube\gmail started demanding RC4. Another "funny" example of this was oculusvr.com oculusvr.com/order/ redirects to https://www.oculusvr.com/order/ https://www.oculusvr.com/order/ requires RC4 and RSA, doesnt like diffiehelman and AES BUT https://support.oculusvr.com/home https://support.oculusvr.com/home less critical part of the site works with more secure AES/DH So the part of the site that deals with confidential data and money defaults to BROKEN crypto, while bugtracker works fine with secure crypto. W T F????
- mnutt 12y ago
  Their support site is most likely hosted by Zendesk, who have a different configuration.
vilda 12y ago
sslscan --no-failed youtube.com: Supported Server Cipher(s): Accepted SSLv3 256 bits ECDHE-RSA-AES256-SHA Accepted SSLv3 256 bits AES256-SHA Accepted SSLv3 168 bits ECDHE-RSA-DES-CBC3-SHA Accepted SSLv3 168 bits DES-CBC3-SHA Accepted SSLv3 128 bits ECDHE-RSA-AES128-SHA Accepted SSLv3 128 bits AES128-SHA Accepted SSLv3 128 bits ECDHE-RSA-RC4-SHA Accepted SSLv3 128 bits RC4-SHA Accepted SSLv3 128 bits RC4-MD5 Accepted TLSv1 256 bits ECDHE-RSA-AES256-SHA Accepted TLSv1 256 bits AES256-SHA Accepted TLSv1 168 bits ECDHE-RSA-DES-CBC3-SHA Accepted TLSv1 168 bits DES-CBC3-SHA Accepted TLSv1 128 bits ECDHE-RSA-AES128-SHA Accepted TLSv1 128 bits AES128-SHA Accepted TLSv1 128 bits ECDHE-RSA-RC4-SHA Accepted TLSv1 128 bits RC4-SHA Accepted TLSv1 128 bits RC4-MD5 Prefered Server Cipher(s): SSLv3 128 bits ECDHE-RSA-RC4-SHA TLSv1 128 bits ECDHE-RSA-RC4-SHA Seems like a problem in cipher ordering?
- 12y ago

nodesocket 12y ago

We (https://commando.io https://commando.io) use: ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"; Which results in perfect forward secrecy and an A+ rating in SSL Labs.

poobrains 12y ago
Is that the same as Ivan Ristic's recommendation at https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy https://community.qualys.com/blogs/securitylabs/2013/08/05/c...
edwintorok 12y ago
Which means you shouldn't trust that A+ single metric without actually looking at the browser list or testing it yourself. I just opened your site on Debian unstable with latest Iceweasel/Firefox 24.5.0, and I get connected via RC4. Arguably thats also NSS's fault for implementing TLS1.2 so late, but still... My site only gets an "A" rating, but Firefox actually connects using ECDHE-RSA-AES256-SHA. I use this cipherlist HIGH:!SSLv2:!aNULL:!3DES Which one is more secure?
- vilda 12y ago
  The difference between A and A+ is in Strict-Transport-Security HTTP header.

tedivm 12y ago

Anyone else remember back in 2012 when CloudFlare promised to open source their intermediary chain information? >Going forward, in addition to releasing the directory of intermediate SSL certificates on Github, we plan on releasing our SSL bundler as a free service so you can package up your SSL certificates as efficiently as possible, even if you're not using CloudFlare. Just one more way we're working to make the web fast and safe. http://blog.cloudflare.com/what-we-just-did-to-make-ssl-even-faster http://blog.cloudflare.com/what-we-just-did-to-make-ssl-even... I hate companies who lie about releasing stuff. If you look through CloudFlare's blog this isn't even the only example- they love promising to be open and give back to the community, but rarely do their actions match their words.

korzun 12y ago
This is pretty silly. They give back to the community and even offer free plans that are pretty damn useful. With amount of growth they have experienced, you should be thankful that they are able to find time for anything at all at this point.
xxdesmus 12y ago
I'll mention this internally. Thank you for the reminder (genuinely). I'll see what I can do about getting this information open sourced. [[UPDATE]] I'm hearing this is still planned, and we're aiming to get this out this coming summer. Internal projects have pushed this back a bit, apologies.
eastdakota 12y ago
We got distracted by other things and never got around to packaging up the packager in a way appropriate for public consumption. You will be happy to know that about a month ago we restarted that project and the team working on it is close to releasing it to the community.
forrestthewoods 12y ago
And comments like this are why companies hate to say anything publicly! If a company says "we plan to..." then odds are they are telling the truth. At the time of writing that is exactly what they were planning to do. It turns out that sometimes plans change. Or planned things take longer than initially planned for. But of course if you ever say anything on the internet people treat it like a promise and then you get called a liar. This is why we can't have nice things.

wzy 12y ago

How does my set up compare to the one CloudFlare and Mozilla is using ssl_ciphers ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM;

edwintorok 12y ago
Don't enable the MEDIUM ciphers, don't use RC4.

edwintorok 12y ago

I'm not a fan of explicitly listing cipher names: when new ciphers are added you have to revise your list again, etc. I very much prefer the simplistic approach taken by OpenSMTPD: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/smtpd/ssl.h?rev=1.7 http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/smtpd/ssl... #define SSL_CIPHERS "HIGH:!aNULL:!MD5"

throwaway7767 12y ago
It really bothers me that 3DES is counted in the HIGH set in OpenSSL. The HIGH set, in my mind, should include only strong ciphers that would make sense to deploy in a new product today. Otherwise, I would love to just say to the crypto library, "give me strong ciphers only".
- kjs3 12y ago
  In what sense is 3DES not strong?
  - edwintorok 12y ago
    Its security strength is less than 2^128, doesn't mean its completely broken but there are better alternatives: https://en.wikipedia.org/wiki/Triple_DES#Security https://en.wikipedia.org/wiki/Triple_DES#Security

escapologybb 12y ago

If I have multiple VirtualHosts defined in Nginx for my two personal websites, should I define these ciphers in each file in sites-enabled or define them in the /etc/nginx/nginx.conf file? Totally realise this is a Newbie question, but I'm finding it hard to get an authoritative answer from my bumbling Googling. I really want to get this right and I thought that the hive mind here on Hacker News would be able to give me an answer that I could trust. Please downvote this if I've made a faux-hacker-pas, but be kind to the new guy! :-)