Browse safer by disabling SSLv3 in Firefox

vulnerable poodle sslv3

You may be at risk! A man-in-the-middle attack may be effective between you and any site that runs on HTTPS. This is explained two days ago by Google in their publication about the POODLE attack. It explains that SSLv3 has a vulnerability and negotiation of this protocol can be enforced by a man-in-the-middle. That man-in-the-middle is able to read (part of) the plaintext of your secure communication with the server. You can click the above image (that links to and if you are vulnerable you will see a poodle.

Fixing the vulnerability is also very easy. If you run a server you may want to check out my post on fixing the POODLE issue in Nginx and Apache. Even transfers from browsers that are not fixed can then no longer be intercepted  and decoded by a man-in-the-middle.

firefox poodle fix

But you should also fix this issue in your browser right now! In Firefox you simply type “about:config” in the address bar and then “tls” in the search bar. Change the value of “security.tls.version.min” from “0” to “1” as the above screenshot illustrates:

Mozilla says that it is making Firefox 34 safe from POODLE by disabling SSLv3 by default. –

This change is so easy (only costs a few seconds and requires a browser restart) that I would not wait for Mozilla to release Firefox 34. If you run another browser, and you are looking for a guide, you may want to check out


Fix Ubuntu SSLv3 POODLE issue in Nginx and Apache

Are you running an HTTPS website on Ubuntu (or any other Linux) with Nginx or Apache? You may be at risk! A man-in-the-middle attack may be effective. This is explained yesterday by Google in their publication about the POODLE attack. POODLE is an acronym for “Padding Oracle On Downgraded Legacy Encryption”. The attack uses a fall-back to the 18 year old “SSLv3” protocol. The security researchers propose that the easiest “fix” is to disable this legacy SSL variant. Fortunately only a small part of your visitors will be impacted:

All modern browsers and API clients will support TLSv1 and later. Disabling SSLv3 will inconvenience WindowsXP users who browse using Internet Explorer 6 – nginx blog

The attack is registered as CVE-2014-3566. Now let’s quickly look at the commands we need to execute:

Disable SSLv3 on Apache

1) We need to edit the file that holds the Apache SSL configuration:

sudo nano /etc/apache2/mods-enabled/ssl.conf

2) Find the following line:

SSLProtocol all -SSLv2

3) Add the option “-SSLv3” so that the line will look like this:

SSLProtocol all -SSLv2 -SSLv3

4) Now restart Apache to make the change effective:

sudo service apache2 restart

Disable SSLv3 on Nginx

1) We need to search in all virtualhost configuration files for the use of the “ssl_protocols” directive:

maurits@nuc:~$ grep -R ssl_protocols /etc/nginx/sites-*
/etc/nginx/sites-available/default:    ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;

2) We need to edit each file that holds the “ssl_protocols” directive:

sudo nano /etc/nginx/sites-available/default

3) Find the following line:

ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;

4) Remove the option “SSLv3” so that the line will look like this:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

5) Now restart Nginx to make the change effective:

sudo service nginx reload

Bonus: Disable SSLv3 on HAProxy

1) Edit the “/etc/haproxy.cfg" file and find your “bind" line. Append “no-sslv3". For example:

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

2) Now restart HAProxy to make the change effective:

sudo service haproxy reload


You should disable SSLv3 on all applications you run, so also on your IMAP/POP3/SMTP daemons. Think about Courier-imap, Dovecot, Sendmail and Postfix. For more information read this post on AskUbuntu.

Testing your server

A server that does not support SSLv3 will give the following output when trying to force a SSLv3 connection:

maurits@nuc:~$ openssl s_client -connect -ssl3 < /dev/null 2>&1 | grep New
New, (NONE), Cipher is (NONE)

A server that is still supporting SSLv3 (and may thus be vulnerable) will give the following output:

maurits@nuc:~$ openssl s_client -connect -ssl3 < /dev/null 2>&1 | grep New
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-RC4-SHA

NB: You can also test other services with this command, but then you need to change 443 to the appropriate port number.



IPv4, HTTPS and Microsoft browsers

Server Name Indication (SNI) allows a server to present multiple certificates on the same IP address and port number. source: Wikipedia

Most cloud instances, virtual machines or dedicated servers are sold with a single IPv4 address, because the Internet is running out of IPv4 addresses. Still, you may need multiple IPv4 addresses to serve multiple sites using HTTPS. This is true unless you use SNI, because SNI allows you to server multiple secure sites with a single IPv4 address. There is a caveat: SNI is not supported by all browsers. “As of November 2012, the only major user bases whose browsers do not support SNI appear to be users of Internet Explorer 8 or below on Windows XP and versions of Java before 1.7 on any operating system.” according to the Wikipedia article on the subject.

Although worldwide in Januari 2013 the percentage of Internet Explorer 8 users is 23 percent (another source reports 11 percent) you might choose not to care. This sounds harsh and not particularly wise commercially seen, but you would not stand alone. Google chose to go that path as well and pulled support for Internet Explorer 7 in July 2011 and for Internet Explorer 8 in November 2012. Such a giant choosing this path might mean that most consumers will stop using Internet Explorer 7 and 8.

For the corporate audience this is different. One reason Internet Explorer 8 is hard to kill off is that large corporations are conservative about operating system upgrades and it is the most up-to-date version of Internet Explorer for Windows XP. Another reason corporate audience might adopt slower to new Internet Explorer versions is that cloud services Gmail and Google Apps are not very common among large corporations, maybe because these companies are scared of storing data in the cloud.

So if you are targeting a tech savvy consumer audience you may consider to use SNI. With the price of certificates dropping and the use of wireless devices on the rise, you might want to consider to at least offer your website on HTTPS for customers that support SNI (you may want to either warn or block them if they do not support SNI). Here is how your virtualhost configuration file would look for a SNI enabled site (in “/etc/apache2/sites-available/leaseweblabs”):

SSLStrictSNIVHostCheck off
<VirtualHost *:443>
DocumentRoot /home/leaseweblabs/public_html

SSLEngine on
SSLProtocol all -SSLv2

SSLCertificateFile /etc/apache2/ssl/leaseweblabs-ssl.crt
SSLCertificateKeyFile /etc/apache2/ssl/leaseweblabs-ssl.key
SSLCertificateChainFile /etc/apache2/ssl/leaseweblabs-ca.bundle


<VirtualHost *:80>
DocumentRoot /home/leaseweblabs/public_html

RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} !MSIE\ [6-8] [NC]
RewriteRule ^(.*)$$1 [R=301,L]


The line containing “%{HTTP_USER_AGENT}” will exclude IE 6-8 users to be redirected to the secured version. This is not perfect, since there may be browsers (like FireFox 3.6) that do not support SNI and do get redirected to HTTPS. You can consider adding “RewriteCond” statements for these specific cases. But even without alterations the setup above feels like a good trade-off between security and compatibility: Your website will be secure for the majority of visitors and also accessible for almost all of them sine all major browsers and their popular versions are supported.

Warning, rant ahead…

So maybe the browser you love to hate has improved by supporting SNI in versions 9 and 10. For me, that is not enough. In my opinion, the SNI feature should be offered as a critical security update for Internet Explorer 8 (and even 7). This is technically possible and the only ethical thing to do with IPv4 running out. So Microsoft, the ball’s in your court, so to speak.