CloudFlare's internet-facing SSL cipher configuration | Hacker News Reader

CloudFlare's internet-facing SSL cipher configuration

github.com

56 pointsFiloSottile40 comments

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

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

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

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.

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.

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.

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.

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.

Then companies should stop promising things if they are not sure when and if they can actually deliver.

https://github.com/holman/feedback/issues/534#issuecomment-4...

Valve takes the same approach.

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.

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.

>This is why we can't have nice things

More like this is why we can't have nice promises. Promises, on their own, are useless. Why should you get the PR boost from an openness promise if you don't actually end up fulfilling it? This is pretty much like false advertising, where you promise some aspects of a product and end up delivering something different. No matter your excuse, this is wrong and unfair to competitors.

But business is business and companies still end up making those weak promises to grab some more market share.

Because it wasn't a god damned promise!! There should be nothing wrong with saying "this is our current plan" and that plan changing down the road (when it makes sense to change).

Anyone who has ever worked on anything in their life knows that plans change. Sometimes plans change to something else that's better. Sometimes ideas that are great on paper don't work in practice and need to be scrapped. Sometimes a plan is a great idea but an unanticipated roadblock makes it impossible or prohibitively expensive to accomplish.

So yes. Companies can never say anything publicly until it's already done. And I think that's a god damned shame. So again I say, this is why we can't have nice things.

Companies can never say anything publicly until it's already done. And I think that's a god damned shame.

Why?

Of course plans change can change.

That said, we all know "that guy". You know, the slick "idea guy" marketer who always has grand plans but never follows through? Who jumps on any hot PR topic that gets him publicity? After a while, you sort of tune him out, because you know his plans never amount to anything.

I have no idea whether cloudflares efforts fall into this pattern. But I know enough companies that behave this way that I think I can safely say that not all corporate "plans" are announced with the intentions of actually following through on them.

I've learned to not hold my breath when companies talk about releasing stuff (e.g. an API), especially when they say they're "working hard" on it...

We (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.

Is that the same as Ivan Ristic's recommendation at https://community.qualys.com/blogs/securitylabs/2013/08/05/c...

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?

The difference between A and A+ is in Strict-Transport-Security HTTP header.

I use 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.

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

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

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

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

In what sense is 3DES not strong?

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

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

https://community.qualys.com/blogs/securitylabs/2013/03/19/r...

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.

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"

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.

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

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/

requires RC4 and RSA, doesnt like diffiehelman and AES

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

Their support site is most likely hosted by Zendesk, who have a different configuration.

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?

If I remove any support for RC4 under chrome, no videos will play. Youtube itself will load, but no video using either flash or html5.

Confirmed with FIrefox Aurora as well.

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

I used 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.

Shouldn't nginx default to the best cipher set?

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

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;

Don't enable the MEDIUM ciphers, don't use RC4.

Reply on news.ycombinator.com