[xt]

Here's relevant nginx configuration to disable SSLv3:

  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:EECDH+RC4:RSA+RC4:!MD5;
  ssl_prefer_server_ciphers on;

This ciphersuite is recommended by CloudFlare.

[thibaut_barrere]

For those who want to verify their change after updating the configuration (since I looked for such information): either use "nmap --script ssl-enum-ciphers -p 443 <host>" or ssllabs (eg: https://www.ssllabs.com/ssltest/analyze.html?d=wisecashhq.co...) and you will see the enabled protocols.

[pixl97]

For those running IIS, use IIS Crypto by Nartac Software for a decent GUI on configuring your protocol and cipher options.

[dchest]

If you use SNI (many domains on one IP), make sure to put this (ssl_protocols TLSv1 TLSv1.1 TLSv1.2;) into the default server { ... } config (or the first one: the one which opens when you go to https://your_server_ip).

[jackalope]

Or better yet, don't serve any content from the default. I actually return a 403 error for the default host or any request without a Host header.

[dchest]

The problem is that if you specify ssl_protocols somewhere else rather than default/first server, it won't work. So, yes, serve error, but specify ssl_protocols in there.

[hrjet]

Why not just disable the default server? (genuine question; I don't know if there are drawbacks to it)

[jackalope]

With name-based virtual hosts (those that rely on the server selecting the appropriate resource based on the Host header), typical clients depend on the IP address returned by DNS for that host. If they visit that IP, ask for the host, and the server isn't configured to deliver that host's resources, it's good practice to give the client an error. Since the web server has to listen on that IP without knowing which host will be requested before the connection is made, it's convenient to have a fallback and handle errors there. I deny all access to the default host, which generates a 403 Forbidden error (with a custom message), but there are definitely other ways to deal with this situation.

The important thing is that a host's protected resources are served only when SSL/TLS is properly negotiated. Serving one host's content as the default when another host was requested violates this.

In practice, nearly all of these requests come from bots, crawlers and penetration testers. So another advantage is that the log entries can be used to block further requests at the firewall, freeing resources and even possibly protecting the server from undisclosed vulnerabilities (test this approach carefully to make sure it's appropriate for your site and doesn't subject you to a DoS).

[praseodym]

This works, but from TFA:

"Disabling SSL 3.0 support … presents significant compatibility problems"

"Therefore our recommended response is to support TLS_FALLBACK_SCSV."

[sslalready]

Disabling SSLv3 will indeed affect a significant amount of clients in the real world.

I've seen a few commenters here on HN that point out that pretty much everything since Windows XP (ignoring IE6) supports at least 1.0 of the TLS protocols. While that may be correct in theory, in practice it's not.

At a 1MM+ visitors/week site we still see a few percent of our users that regularly connect using SSLv3 across different versions of Windows, including more modern ones such as Windows Vista, 7 and 8(!)

Though I'm not sure why this is the case, antivirus software suites such as McAfee[1] have in the past been known to disable TLS 1.0 system wide in Windows.

[1] http://answers.microsoft.com/en-us/ie/forum/ie8-windows_othe...

[cesarb]

It's well-known that the fallback can be triggered by accident, see for instance https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00:

"[...] Also, handshake errors due to network glitches could similarly be misinterpreted as interaction with a legacy server and result in a protocol downgrade."

Perhaps that's what you're seeing.

[modoc]

CloudFlare sees 0.65% of HTTPS traffic using SSL v3 so it's a pretty small impact.

[ParadisoShlee]

and of that 0.65% - 98% of them have the ability to connect over TLS.

so we're talking 2% of 1% that are dead in the water.

[zobzu]

Except if you force downgrade browsers. So they nee to actually support the extension to prevent that.

[Buge]

The point was that if you disable SSLv3, you will cut off some users from your site, but only 0.65%, so it's not that bad of an effect.

[warp]

Does anyone have any idea what kind of clients would require SSL3 to stay enabled? Old android phones and/or Windows XP perhaps?

[cesarb]

Quoting myself (https://news.ycombinator.com/item?id=8453718):

"For clients, a quick look at https://www.ssllabs.com/ssltest/clients.html shows that even older clients (Android 2.3, Java 6, the oldest supported version of IE, etc) support TLS 1.0, so there should be no issues disabling SSLv3 on servers too."

[wiredfool]

IE6/XP According to Qualsys.

[ck2]

IE6 on XP can actually use TLS, it is just not enabled by default.

But IE8 is readily available on XP so who would use IE6

[wiredfool]

I think it's probably safe to say that anyone who's using IE6 is either not one who cannot change the defaults (by policy or by skill) or their machine is already malware infested.

[jabo]

Source for the Cloudfare configuration: https://github.com/cloudflare/sslconfig

[justcommenting]

Firefox disabled a bunch of ciphers on the client side with today's release as well

[briansmith]

If you are referring to https://bugzilla.mozilla.org/show_bug.cgi?id=1036765, that was an unrelated change that was made well in advance of my knowledge of this issue.