
CloudFlare's internet-facing SSL cipher configuration - FiloSottile
https://github.com/cloudflare/sslconfig
======
latimer
Here's Mozilla's version:
[https://wiki.mozilla.org/Security/Server_Side_TLS#Recommende...](https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Ciphersuite)

~~~
praseodym
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)

------
tedivm
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...](http://blog.cloudflare.com/what-we-just-did-to-make-ssl-even-faster)

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.

~~~
forrestthewoods
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.

~~~
Pacabel
If a person or organization says that they're going to do something, even if
it's qualified as only being "planned", it is indeed a promise to act.

Reputable people and organizations who make such statements will then proceed
to deliver. If they suspect they won't be able to, for whatever reason, then
they'll be careful not to make such statements in the first place.

There's absolutely nothing wrong with holding people and organizations to a
very high standard regarding what they've publicly claimed that they will or
aim to do.

~~~
bmm6o
You seem to have an excessively narrow definition for planning. If I plan to
go to the gym today and it turns out that I do not, would you really say that
I broke a promise? Something else came up and I changed my plans. It's
possible I lied to you when I told you about my plans, but that is not the
same thing as breaking a promise.

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

~~~
edwintorok
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
The difference between A and A+ is in Strict-Transport-Security HTTP header.

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

------
escapologybb
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! :-)

------
edwintorok
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...](http://www.openbsd.org/cgi-
bin/cvsweb/src/usr.sbin/smtpd/ssl.h?rev=1.7)

    
    
      #define SSL_CIPHERS		"HIGH:!aNULL:!MD5"

~~~
throwaway7767
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
In what sense is 3DES not strong?

~~~
edwintorok
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)

------
korzun
Can somebody explain why they are still using RC4 in their configuration?

[https://community.qualys.com/blogs/securitylabs/2013/03/19/r...](https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-
tls-is-broken-now-what)

~~~
huxley
[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"

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

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

~~~
vilda
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?

~~~
sitkack
You need to be looking at the sites serving the video ( r4---sn-
nx57yn7k.googlevideo.com ) not the player itself.

[https://gist.github.com/anonymous/793efa92b17c8f727a1f](https://gist.github.com/anonymous/793efa92b17c8f727a1f)

I used
[https://github.com/DinoTools/sslscan](https://github.com/DinoTools/sslscan)
instead of the one that ships with homebrew.

My favorite preferred cipher is

    
    
            SSLv2  0 bits    (NONE)
    

I try and use that whenever I can.

------
joevandyk
Shouldn't nginx default to the best cipher set?

~~~
korzun
The best cipher set might not be the best for everybody.

------
wzy
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
Don't enable the MEDIUM ciphers, don't use RC4.

