158

After the BEAST attack and Heartbleed bug, now I've heard about a new vulnerability in SSL/TLS called POODLE. How do I protect myself against being exploited?

  • Are only servers or also clients affected?
  • Is this OpenSSL/GnuTLS specific?
  • What kind of services are affected? Only HTTPS or also IMAPS, SMTPS, OpenVPN, etc.?

Please show me examples on how to avoid this vulnerability.

8
  • 2
    More information can be found here SSL3 "Poodle" Vulnerability
    – Braiam
    Oct 15, 2014 at 1:59
  • 1
    @Braiam Yeah I know, the brilliant Thomas again! However, that's a very cryptographic oriented Q&A. This Q&A on AU is supposed to provide practical and Ubuntu oriented info. :-)
    – gertvdijk
    Oct 15, 2014 at 2:03
  • 10
    Huh? How do you expect a more practical solution than "If you do not install the patches then Níðhöggr will devour your spleen."
    – Braiam
    Oct 15, 2014 at 10:24
  • 2
    @Braiam First of all: there is no patch (read my answer). I think that Thomas is referring to appliances rather than DIY-Ubuntu web server hosting. Appliances like load balancers usually offer firmware updates for change of default settings or will offer functionality to be able to configure it. However, in Ubuntu it's all up to the user/administrator.
    – gertvdijk
    Oct 15, 2014 at 13:36
  • Actually there is: vendors can disable/remove all SSLv3 related code, hence you don't need to touch anything, at all.
    – Braiam
    Oct 15, 2014 at 13:38

4 Answers 4

210

Background info

SSL is designed to secure the transport level on the internet. For 'the web' aka HTTP you'll know this as HTTPS, but it's also used for other application protocols. SSLv2 was the first widely used transport security protocol but was found insecure not long after. Successors SSLv3 and TLSv1 are widely supported now. TLSv1.1 and TLSv1.2 are newer and gaining a lot of support too. Most if not all web browsers released from 2014 have support for it.

The recent discovery by Google engineers points out that SSLv3 should not be used any longer (like SSLv2 is deprecated a long time ago). The clients that won't be able to connect to your site/service are probably very very limited. CloudFlare announced that less than 0.09% of their visitors still rely on SSLv3.

Simple solution: disable SSLv3.

Does Ubuntu provide any update?

Yes, via usn-2385-1 with the addition of the SCSV feature, but it does not mitigate the issue completely as it does not disable SSLv3 and the patch will only work if both sides of the connection have been patched. You'll receive it through your regular security updates in your package manager.

So, still YOU have to take action yourself to disable SSLv3 (it's configurable). Future versions of clients/browsers will disable SSLv3 most likely. E.g. Firefox 34 will do so.

Disabling SSLv3 completely by default in Ubuntu on implementation level will probably break some stuff out there also for non-HTTPS SSL usage which is not so much vulnerable, so I assume maintainers won't do that and only this SCSV patch will be applied.

Why does the SCSV update in OpenSSL via usn-2385-1 does not mitigate the issue?

Really, stop asking such questions and just skip a few paragraphs and disable SSLv3. But hey, if you're not convinced, here you go:

POODLE shows that SSLv3 with CBC ciphers is broken, implementing SCSV does not change that. SCSV only makes sure you don't downgrade from some TLS protocol to any lower TLS/SSL protocol as needed with the Man-in-the-Middle attack required for the usual cases.

If you have to access some server which does not offer TLS at all, but only SSLv3, then your browser doesn't really have a choice and has to talk to the server using SSLv3, which is then vulnerable without any downgrade attack.

If you have to access some server which offers TLSv1+ and SSLv3 too (which is discouraged) and you want to be sure your connection will not be downgraded to SSLv3 by an attacker, then both the server and the client need this SCSV patch.

For completely mitigating the issue the disablement of SSLv3 your end is enough and you can be sure you won't be downgraded. And you won't be able to talk to to SSLv3-only servers.

Okay, so how do I disable SSLv3?

See below in the application specific sections: Firefox, Chrome, Apache, Nginx and Postfix are covered for now.

Are only servers or also clients affected?

The vulnerability exists if both the server and client accepts SSLv3 (even if both are capable of TLSv1/TLSv1.1/TLS1.2 due to a downgrade attack).

As a server admin you should disable SSLv3 now for the security of your users.

As a user, you should disable SSLv3 in your browser now to secure yourself when visiting websites which still support SSLv3.

Is this OpenSSL/GnuTLS/browser specific?

No. It's a protocol (design) bug, not an implementation bug. This means you can't really patch it (unless you're changing the design of the old SSLv3).

And yes, there's a new OpenSSL security release, but read below (But I really really need SSLv3 support... for reason X,Y,Z!) on why you'd better focus on disabling SSLv3 altogether.

Can I kill SSLv3 on the network (firewall) level?

Well, yes, probably. I put this in a separate blog post for further thoughts and work. We may have some magic iptables rule you can use!

My blog post: How to take down SSLv3 in your network using iptables for POODLE?

Is it relevant for HTTPS only or also for IMAP/SMTP/OpenVPN and other protocols with SSL support?

The current attack vector, as shown by the researchers, works with controlling the plaintext sent to the server using Javascript being run on the victim's machine. This vector does not apply to non-HTTPS scenarios without using a browser.

Also, normally an SSL client doesn't allow the session to be downgraded to SSLv3 (having TLSv1+ seen in the handshake capabilities), but browsers want to be very backward compatible and they do. The combination with controlling plaintext and the specific way a HTTP header is built up makes it exploitable.

Conclusion: disable SSLv3 for HTTPS now, disable SSLv3 for other services in your next service window.

What's the impact? Do I need to revoke and regenerate my server certificate? (As with Heartbleed)

No, you don't need to rotate your certificates for this. The vulnerability exposes plaintext recovery from the session data, it does not provide access to any secrets (neither the session key or certificate key).

An attacker is most likely only capable of stealing the plaintext headers like session cookies in order to perform session hijacking. An additional constraint is the need for a full (active) MitM attack.

Is there anything else I can do to improve my SSL configuration in general?

As a user, besides disabling SSLv3 in your browser, not really. Well, just always install the latest security updates.

For servers, follow Mozilla's TLS server guide. And test with Qualys' SSL Labs test. It's really not that hard to get an A+ rating on your site. Just update your packages and implement the recommendations from the guide of Mozilla.

But I really really need SSLv3 support... for reason X,Y,Z! Now what?

Well, there's a patch that circumvents the downgrade attack of TLSv1 capable clients, called the SSLv3 Fallback Protection. It will improve the security of TLSv1+ too, by the way (downgrade attack is harder/impossible). It's offered as a backport from a more recent OpenSSL version in the Ubuntu Security advisory usn-2385-1.

Big catch: Both clients and servers need this patch in order to work. So, in my opinion while you're updating both clients and servers you should just upgrade to TLSv1+ anyway.

However, please, please, just retire SSLv3 in your network for now. Put effort in upgrading security standards and just ditch SSLv3.

I heard about SCSV support to eliminate the protocol downgrade attack. Do I need it?

Only if you really need SSLv3 for some odd reason, but it improves security in TLSv1+ too, so yes, I'd recommend you to install it. Ubuntu provides an update for this feature in usn-2385-1. You'll receive it through your regular security updates in your package manager.

Testing vulnerability for privately hosted sites (e.g. intranet/offline).

Your servers are vulnerable simply if they support SSLv3. Several options here:

  • With OpenSSL s_client:

    openssl s_client -connect <server>:<port> -ssl3
    

    If the connection succeeds, sslv3 is enabled. If it fails, it is disabled. When it fails you should see something like:

    error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
    
  • Using nmap:

    nmap --script ssl-enum-ciphers -p 443 myhostname.tld
    

    It should output 'SSLv3: No supported ciphers found'. Adjust for your hostname/port.

  • Using cipherscan. Clone/download the binary and execute it:

    ./cipherscan myhostname.tld
    

    It should not list anything with SSLv3 under the 'protocols' column.


Firefox browser

Open about:config, find security.tls.version.min and set the value to 1. Then restart your browser to drop any open SSL connections.

Firefox from version 34 onwards will disable SSLv3 by default and thus require no action (source). However, at the moment of writing, 33 is just released and 34 is set for November 25.


Google Chrome (Linux)

Edit the /usr/share/applications/google-chrome.desktop file, e.g.

sudo nano /usr/share/applications/google-chrome.desktop

Edit all lines starting with Exec= to include --ssl-version-min=tls1.

E.g. a line like

Exec=/usr/bin/google-chrome-stable %U

becomes

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

Then make sure to fully close the browser (Chrome apps may be keeping your browser active in the background!).

Note: You may need to repeat this every google-chrome package update, overwriting this .desktop launcher file. A Google Chrome or Chromium browser with SSLv3 disabled by default is not yet announced at the time of writing.


Apache HTTPD Server

If you are running an Apache web server that currently allows SSLv3, you will need to edit the Apache configuration. On Debian and Ubuntu systems the file is /etc/apache2/mods-available/ssl.conf. On CentOS and Fedora the file is /etc/httpd/conf.d/ssl.conf. You will need to add the following line to your Apache configuration with other SSL directives.

SSLProtocol All -SSLv2 -SSLv3

This will allow all protocols except SSLv2 and SSLv3.

While you're at it, you may want to consider improving the ciphersuite configuration for your webserver as explained on Mozilla's TLS server guide. Add for example:

SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
SSLHonorCipherOrder     on
SSLCompression          off
# Read up on HSTS before you enable it (recommended)
# Header add Strict-Transport-Security "max-age=15768000"

Then check if the new configuration is correct (no typos etc.):

sudo apache2ctl configtest

And restart the server, e.g.

sudo service apache2 restart

On CentOS and Fedora:

systemctl restart httpd

More info: Apache documentation

Now test it: If your site is publicly available, test it using Qualys’ SSL Labs tool.


Nginx server

If you're running Nginx, just include the following line in your configuration among the other SSL directives:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

While you're at it, you may want to consider improving the ciphersuite configuration for your webserver as explained on Mozilla's TLS server guide. Add for example:

ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_prefer_server_ciphers on;
# Read up on HSTS before you enable it (recommended)
# add_header Strict-Transport-Security max-age=15768000;

And restart the server, e.g.

sudo service nginx restart

Reference: Nginx documentation

Now test it: If your site is publicly, available, test it using Qualys' SSL Labs tool.


Lighttpd webserver

Lighttpd versions >1.4.28 support a configuration option to disable SSLv2 and v3. Lighttpd releases before 1.4.28 allow you to disable SSLv2 ONLY. Please note that Ubuntu 12.04 LTS and earlier install at best lighttpd v1.4.28 and therefore a simple fix is not available for those distributions. Therefore this fix should only be used for Ubuntu versions greater than 12.04.

For Ubuntu version 12.04 or Debian 6, an updated lighttpd package is available from the openSUSE repository: http://download.opensuse.org/repositories/server:/http/Debian_6.0

The package is intended for Debian 6 (squeeze) but works also on 12.04 (precise)

Edit your /etc/lighttpd/lighttpd.conf to add the following lines after the ssl.engine = "enable" directive

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

Then you should restart the lighttpd service with a sudo service lighttpd restart and perform an ssl3 handshake test as described in earlier sections to make sure that the change was implemented successfully.

Taken from http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL.


Postfix SMTP

For 'opportunistic SSL' (encryption policy not enforced and plain is acceptable too), you don't need to change anything. Even SSLv2 is better than plain, so if you need to secure your server you should be using 'mandatory SSL' mode anyway.

For 'mandatory SSL' mode being configured already, just add/change the smtpd_tls_mandatory_protocols setting for inbound connections and smtp_tls_mandatory_protocols for outbound connections:

smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3
smtp_tls_mandatory_protocols=!SSLv2,!SSLv3

Optionally, if you want to disable SSLv3 for opportunistic encryption as well (even though it's unnecessary as explained above), do so thusly:

smtpd_tls_protocols=!SSLv2,!SSLv3
smtp_tls_protocols=!SSLv2,!SSLv3

and restart Postfix:

sudo service postfix restart

Sendmail

(Unverified edit by anonymous user, I'm not comfortable with Sendmail, please verify.)

These options are configured in the LOCAL_CONFIG section of your sendmail.mc

LOCAL_CONFIG
O CipherList=HIGH
O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_CIPHER_SERVER_PREFERENCE
O ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3

Dovecot

In Dovecot v2.1+, add the following to your /etc/dovecot/local.conf (or a new file in /etc/dovecot/conf.d):

ssl_protocols = !SSLv2 !SSLv3

and restart Dovecot:

sudo service dovecot restart

For older versions you will have to patch the source code.


Courier-imap (imapd-ssl)

Courier-imap allows SSLv3 by default on Ubuntu 12.04 and others. You should disable it and use STARTTLS instead to force TLS. Edit your /etc/courier/imapd-ssl configuration file to reflect the following changes

IMAPDSSLSTART=NO
IMAPDSTARTTLS=YES
IMAP_TLS_REQUIRED=1
TLS_PROTOCOL=TLS1
TLS_STARTTLS_PROTOCOL=TLS1
TLS_CIPHER_LIST="<take those from the Mozilla TLS Server guide!>"

HAProxy Server

SSL is supported in HAProxy >= 1.5.

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

Reference: HAProxy Documentation


OpenVPN

Appears to be unaffected (source).

OpenVPN uses TLSv1.0, or (with >=2.3.3) optionally TLSv1.2 and is thus not impacted by POODLE.


Puppet

Puppet uses SSL over HTTPS but it isn't used by 'browser' clients, just Puppet agents which aren't vulnerable to the attack vector shown. However, it's best practice to just disable SSLv3.

My recommendation is to use the stephenrjohnson/puppetmodule Puppet module to set up your Puppet master in which I killed SSLv3 some time ago.

33
  • 7
    This answer was created very very quickly after the public release of the vulnerability. There may be errors in there still - as always, feel free to edit/improve.
    – gertvdijk
    Oct 15, 2014 at 0:32
  • 1
    Nginx config shouldn't have colon after ssl_protocols directive
    – Michelle
    Oct 15, 2014 at 5:04
  • 1
    Alright, for Firefox I believe this is what's going on.
    – fuglede
    Oct 15, 2014 at 11:45
  • 4
    This Mozilla Security blog post suggests installing this add-on instead of tweaking preferences manually.
    – legoscia
    Oct 15, 2014 at 14:22
  • 1
    @muru Here's a start on killing SSLv3 on firewall level. blog.g3rt.nl/take-down-sslv3-using-iptables.html
    – gertvdijk
    Oct 15, 2014 at 22:21
4

Might not be ubuntu specific but in order to work around the Poodle vulnerablity in Node.js you can set the secureOptions to require('constants').SSL_OP_NO_SSLv3 when you create a https or tls server.

See https://gist.github.com/3rd-Eden/715522f6950044da45d8 for addition information

5
  • 1
    IMO you should not be exposing HTTP(S) with Node/Python/Ruby or anything like that directly. Put a decent HTTPd in front of it like Apache/Nginx/...
    – gertvdijk
    Oct 15, 2014 at 11:22
  • Yeah, you shouldn't be exposing directly. Languages aren't that good with tcp layer HTTP, but they rock at doing sockets. Let nginx read it from a socket. :-)
    – jrg
    Oct 15, 2014 at 13:20
  • 4
    This didn't deserve a down vote. There are lots of cases where tls is used besides hosting an http server.
    – psanford
    Oct 15, 2014 at 14:29
  • @gertvdijk & jrg Node.js is not a language. It's a framework for building scalable network applications. And as you state that you should put Node.js behind an Apache server (and even call it "decent") already makes it clear that you have absolutely no idea what you're talking about. Stating that they are not good with tpc/http is obviously personal bias. Please just stay on topic unstead of childishly down voting technology you don't understand.
    – 3rdEden
    Oct 23, 2014 at 12:54
  • @3rdEden Well, perhaps my remark was a bit generalizing, but here are a few notes I'd like to make. 1) I did not downvote, 2) my comment was a gentle 'IMO', 3) Perhaps it's just my background in security, but I've learnt that one should not expose an application framework directly to 80/443 to the world in production. (unless for demonstration purposes). 4) I don't see how your post is an 'answer' to the question for the general Ask Ubuntu visitor; it's just very very specific to a certain specific case of Node.js deployments.
    – gertvdijk
    Oct 23, 2014 at 13:08
0

The "fix" for courier disables tls 1.1 and tls 1.2. There does not appear to be a way to run courier with tls 1.1 or higher. A PCI scan on your server may come back with the recommendation:

Configure SSL/TLS servers to only use TLS 1.1 or TLS 1.2 if supported. Configure SSL/TLS servers to only support cipher suites that do not use block ciphers.

-1

Since POODLE Vulnerability is a design flaw in the protocol itself and not an implementation bug, there will be no patches. Only way to mitigate this is to disable SSLv3 in the apache server. Add the below lines into ssl.conf and do a graceful apache restart.

SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite "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"
4
  • 1
    -1 for including RC4 and non-functional ECDSA as most people have RSA certificates. Please just read up on how to configure your server properly. wiki.mozilla.org/Security/Server_Side_TLS
    – gertvdijk
    Oct 15, 2014 at 22:57
  • 2
    @gertvdijk I agree with you about RC4, but it doesn't hurt to include ECDSA suites. It's harmless if you only have an RSA cert and saves you the trouble of fixing your config if you later get an ECDSA cert. Oct 17, 2014 at 2:37
  • @MattNordhoff Fair enough, but what I mean is that not many ciphers are left for a regular RSA certificate based configuration. It will work in most browsers, but one may face compatibility issues.
    – gertvdijk
    Oct 17, 2014 at 7:24
  • Definitely get rid of RC4 from this list, that's not safe. Stay with the remaining if you can. 3DES is weak, but I've turned that on in one particular place for compatibility. I hate to do it since it's weak, but at least it's not actually broken... Nov 21, 2014 at 16:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .