How to disable SSLv3

One-stop resource on how to effectively disable SSLv3 in major web browsers as well as in web, mail and other servers that may still be using it.

Check the SSL/TLS setup of your server or CDN


SSL, and its successor TLS, are cryptographic protocols designed to provide communication security over the Internet. In the web realm, they are providing HTTPS, but they are also used for other application protocols. SSLv1 was never publicly released, and SSLv2 was quickly found to be insecure. SSLv3 was created, and, together with the newer TLSv1/1.1/1.2, it is still currently being used to secure the transport layer of the Internet.

As it happened for SSLv2, recently Google engineers pointed out that SSLv3 is broken (with an exploitation technique known as POODLE) and should not be used any longer. There is a patch, but it does not mitigate the issue completely as it will work only if both sides of the connection have been patched. SSLv3 is nearly 18 years old, but support for it remains widespread. Clients and servers should disable SSLv3 as soon as possible. While there is a tiny fraction of Internet users that run very outdated systems that do not support TLS at all, clients that won't be able to connect to your website or service are limited: CloudFlare announced on October 14th 2014 that less than 0.09% of their visitors still rely on SSLv3.


Why do I have to disable SSLv3 on servers?

If you are a server administrator, you really should disable SSLv3 now for the security of your users. By doing this, clients will no longer be able to use the insecure SSLv3 protocol to connect to you, and will have to use a newer, more secure alternative.

Why do I have to disable SSLv3 on clients?

As a user, you should disable SSLv3 in your browser now to secure yourself when visiting websites that still support SSLv3. By doing this, you will be sure your client won't attempt to establish a connection with SSLv3 and will use a more secure alternative.

Is POODLE an implementation vulnerability such as the OpenSSL Heartbleed bug?

No, POODLE is a protocol vulnerability. This means this is inherent in the inner workings of SSLv3, and you can't really patch it.

I am a server administrator. Do I need to revoke certificates after POODLE?

No, you don't need to issue a new certificate. The POODLE attack is not a memory leak, it is a plaintext recovery attack that focuses on HTTP headers and exploits a weakness in the SSLv3 protocol when used with block ciphers.

But I heard there was a patch...

A possible mitigation, to be implemented on both the server and the client, is to add support for the TLS Fallback Signaling Cipher Suite Value (TLS_FALLBACK_SCSV). This new feature prevents protocol downgrade attacks when certain applications such as web browsers attempt to reconnect using a lower protocol version. It also prevents downgrades from TLS 1.2 to 1.1 or 1.0 and so may help prevent future attacks. You will get this patch in your regular software updates, but it is not enough, since it will work only if both sides of the connection have been patched.

About clients, is there any software other than web browsers vulnerable to POODLE?

Maybe. The attack scenario requires the attacker to be able to inject data of their own, and to intercept the encrypted bytes. The most natural context where such a thing happens is a web browser, but we can't exclude other clients could be vulnerable to a POODLE-like technique.

I would like to get more technical details about POODLE.

Please see the security advisory by Google and this answer on StackExchange.

I would like to report an error in your page or add instructions for new widely used software!

Great, please leave a comment in the comment section at the bottom of the page.

Web browsers

Chrome and Chromium

From Chrome 39, fallback to SSLv3 is disabled by default. If you are using Chrome ≥ 40 you are safe, because Chrome/Chromium has disabled SSL 3.0 support completely.

Chrome and Chromium used to have a setting in preferences to let the user specify the preferred protocol, but people allegedly thought that SSL 3.0 was a higher version than TLS 1.0 and would mistakenly disable the latter (source: ImperialViolet).

So, until a Google Chrome or Chromium browser with SSLv3 disabled by default is announced, it is necessary to run Chrome/Chromium with a command line flag:


If you want, you can modify the shortcut to make it run with the correct flag.


  1. Right click on the Google Chrome / Chromium shortcut on the Desktop, and click Properties.
  2. In Target, after the last character (a quote), add a space and then --ssl-version-min=tls1.
  3. Click OK, and confirm if it asks for administrator privileges.

Please note that this protects normal browser sessions initiated by clicking on the shortcut on the desktop, but not sessions started by clicking a link in a document or in an email from an external program. To protect every session, you have to set the ChromeHTML/shell/open/command registry value in HKEY_CLASSES_ROOT to "C:\Program Files\Google\Chrome\Application\chrome.exe" --ssl-version-min=tls1 -- "%1" (make sure the path to chrome.exe is correct for your system). — thanks to Dr. Thomas Kunst

Linux / Unix

The process for changing the symbolic links on your desktop and in the application menu vary between different desktop environments.

For instance, in Ubuntu, you have to edit the /usr/share/applications/google-chrome.desktop file, and edit all lines starting with Exec= to include --ssl-version-min=tls1.

As an example,

Exec=/usr/bin/google-chrome-stable %U
Exec=/usr/bin/google-chrome-stable --ssl-version-min=tls1 %U

Then save the file and restart the browser. — thanks to gertvdijk on AskUbuntu

Chromium only: on the stable releases of Debian and Ubuntu, edit /etc/chromium-browser/default and add:


On the unstable release of Debian, create /etc/chromium.d/disable-sslv3 with content:

CHROMIUM_FLAGS="${CHROMIUM_FLAGS} -ssl-version-min=tls1"

thanks to David McBride

Mac OS X

Open AppleScript Editor (in /Applications/Utilities/), and type this in:

do shell script "open '/Applications/Google' --args --ssl-version-min=tls1"

Save it as an Application, and add that application to the Dock.

Mozilla Firefox

Mozilla announced that SSLv3 will be disabled by default in Firefox 34, which will be released on November 25th 2014.

In the meantime:

  1. Type about:config in the address bar and press Enter
  2. Set the value of security.tls.version.min to 1


Apple has released Security Update 2014-005, which disables CBC-mode ciphers in coordination with SSLv3. The patch is available for Mac OS Mavericks, Mountain Lion, and Yosemite, and once you updated no action is needed on your part.

Internet Explorer

To disable SSLv3 in Internet Explorer:

  1. Open Internet Options from the Start menu
  2. Click the Advanced tab
  3. Uncheck Use SSL 3.0
  4. Confirm by clicking OK

If you have an older version of Windows, such as Windows XP, make sure it is at least patched with SP3 to be able to access sites with SSLv3 disabled.


Opera 12 disabled SSLv3 support, so if you updated you should be safe.

If you are using Opera 12.17 or older:

  1. Press ctrl + f12
  2. Click the Advanced tab
  3. Click on Security on the left menu
  4. Click on Security protocols
  5. Uncheck Enable SSL 3
  6. Click OK

Web servers


Put the following line in your configuration file, or replace any existing line starting with SSLProtocol:

SSLProtocol All -SSLv2 -SSLv3

Then run: sudo apache2ctl configtest && sudo service apache2 restart.

Don't forget to test your website.


Put the following lines in a file named disable_ssl3.reg:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]

Then click on it.

Don't forget to test your website.


Put the following line in your configuration file, or replace any existing line starting with ssl_protocols:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Then restart the server (in Ubuntu: sudo service nginx restart).

Don't forget to test your website.


Lighttpd releases before 1.4.28 allow you to disable SSLv2 only.

If you are running at least 1.4.29, put the following lines in your configuration file:

ssl.use-sslv2 = "disable"
ssl.use-sslv3 = "disable"

Then restart the server (in Ubuntu: sudo service lighttpd restart).

Don't forget to test your website.

Mail servers


Put the following lines in your configuration file, in the LOCAL_CONFIG section:

O CipherList=HIGH
O ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3

Then restart the server (in Ubuntu: sudo service sendmail restart).


Put the following lines in your configuration file, or modify existing:


Then restart the server (in Ubuntu: sudo service postfix restart).


Put the following line in your /etc/dovecot/local.conf configuration file, or modify existing:

ssl_protocols = !SSLv2 !SSLv3

Then restart the server (in Ubuntu: sudo service dovecot restart).


Put the following line in your /etc/courier/imapd-ssl configuration file, or modify existing:


Then restart the server (in Ubuntu: sudo service courier-imap restart).



Open the Java Control Panel (in Windows, Start -> Java -> Configure Java). Expand the Advanced tab and scroll down. There you can unmark the Use SSL 3.0 box.


If you are using NodeJS as a web server (which might not be a good idea), you should set secureOptions to:

constants.SSL_OP_NO_SSLv3 | constants.SSL_OP_NO_SSLv2

More info in this Gist by 3rd-Eden.


OpenVPN uses TLSv1.0, or, starting with version 2.3.3, optionally TLSv1.2 and is thus is not impacted by POODLE.


Puppet agents are not vulnerable to POODLE.

If you still want to disable SSLv3, you can use the stephenrjohnson/puppetmodule Puppet module to set up your Puppet master, which doesn't support SSLv3.


Edit the bind line in your /etc/haproxy.conf configuration file, and append no-sslv3.

For example:

bind :443 ssl crt <crt> ciphers <ciphers> no-sslv3

For more information see the HAProxy documentation.

How to test SSLv3 support

Test if your server supports SSLv3

You can check your enabled SSL/TLS protocol versions.

If your server is exposed to the Internet, and you don't mind sharing the hostname with a third party service, you can use web tools such as Tinfoil.

If, on the other hand, you want to check this manually, you can use openssl on any Unix machine:

openssl s_client -connect <host>:<port> -ssl3
A host that has SSLv3 disabled will return an error with handshake failure in it.


This page was compiled by Michele Spagnuolo.