Today a new vulnerability was announced in SSLv3. The vulnerability allows attackers who might be in a position to execute a MITM (Man In The Middle) attack against a client to decrypt SSLv3 traffic. Luckily, SSLv3 hasn't been used by clients (web browsers) for a number of years now, replaced by TLS.

At Recurly we supported SSLv3 for backwards compatibility purposes. As it turns out, supporting SSLv3 as of today puts other clients at risk due to a MITM attack potentially forcing a client (web browser) to fall-back to SSLv3, thereby allowing them to disable encryption and view your website traffic. Today, in order to protect our clients we have removed the ability to use SSLv3 with Recurly and in turn, the ability for our clients to be exposed to this issue when using Recurly.

How do I protect myself?

Not all providers will be as quick to act, therefore we recommend that you use an up-to-date web browser like Google Chrome which prevents the attack.If you are a service provider, the best way to protect your customers is by disabling SSLv3. Detailed below is how you accomplish this with modern web servers:

NGINX

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;

Apache HTTPD

SSLProtocol All -SSLv2 -SSLv3 SSLCipherSuite EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:

Testing clients

Some testing clients such as PhantomJS are using SSLv3 to connet, which is no longer accepted by Recurly. Updating configs to instead use TSLv1 has been a proven remedy to this issue. Check the issues section of your client's repo for more information about using TSLv1.

Where can I find out more?

The technical details of the exploit may be found here).A detailed blog post about how many people this effects, along with some more information can be found here.