Do We Need to Worry About PoodleBleed?

[Siamese-Dream.Com]

Another day, another new security vulnerability...

Do us folks who are hosted with Miva need to worry about poodle bleed hack?

[ILoveHostasaurus]

Re: Do We Need to Worry About PoodleBleed?

SSLv3 was disabled across our servers last week. The problems we've learned of since that time have been primary users of Shipworks, for which an update is available, and users of Microsoft Outlook for Macintosh, as apparently Microsoft Outlook for Mac does not yet know about TLS, even though it came about 15 years ago. Other than that, the only effects should be shoppers using IE 6 on Windows XP, which is arguably a very small number, for example, Cloudflare (at http://blog.cloudflare.com/sslv3-sup...vulnerability/) says they see 3.12% of their traffic coming from XP and of that, only 1.12% was using SSLv3.

[skepticwebguy]

Re: Do We Need to Worry About PoodleBleed?

I am on a self-managed server, and I use the following settings in my miva.conf file. Is this an issue with POODLE?

cadir=/path/to/certs/openssl-0.9
openssl=/lib64/libssl.so.6
openssl_crypto=/lib64/libcrypto.so.6

I tried switching cadir to openssl-1.0, but then my PayPal Express Checkout returns this error:

Paypal Express Checkout Error: Network error: Unable to open URL 'https://api-3t.paypal.com/2.0/': Error establishing SSL connection: certificate verify failed (-3)

I'm running:

Miva Merchant 5.5
Production Release 8 Update 12
Miva Merchant Engine v5.19

[ILoveHostasaurus]

Re: Do We Need to Worry About PoodleBleed?

The fact that you're on engine version 5.19 means you do not have to worry about not being able to connect to a remote server that has been locked down for poodle, i.e. SSLv3 disabled.

To prevent your own server from having insecure SSLv3 connections come into it, that is not going to be related to Miva Merchant, the engine (Empresa) or their versions. That change needs to be performed on the server with a config update to every daemon that offers remotely accessed SSLv3 services, but the ones that are particularly vulnerable are email services and web services, since they both would exchange the same bit of information over and over, which is what the SSLv3 exploit needs to be successful. For example, if a customer of yours is logged in, their session cookie is going to be coming across the wire repeatedly as they click around the site. Or if you're logged into the admin interface, your session cookie will be going across the wire with each request. On email, your password is going to be the first thing sent every time your email client connects. These are all susceptible to the SSLv3 attack.

On your server, you'd want to look at the config for apache, nginx or whatever web server software you use. Postfix, Courier, Sendmail, etc. for whichever email server software(s) you use.

I would recommend using the following page as a reference; ideally use the "intermediate" config for all services, both the protocol and cipher adjustments:

https://wiki.mozilla.org/Security/Server_Side_TLS

[skepticwebguy]

Re: Do We Need to Worry About PoodleBleed?

Thank you, David


My host pointed out that the Parallels website provides a handy script from Linux and Windows machines to disable SSLv3 for all the services. You can find the download links here: http://kb.sp.parallels.com/en/123160


That made it super fast and easy to secure my server. The webpage also provides another script I used to check that services were no longer vulnerable to poodle attacks. I ran that script and confirmed that my server is secure now.

Cheers
Will

[ILoveHostasaurus]

Re: Do We Need to Worry About PoodleBleed?

I've seen their script but it is not very good. There are are a number of issues:

1) Depending on the contents of the /etc/httpd/conf.d/ssl.conf, their newly created /etc/apache2/conf.d/ssl_disablev3.conf may not work, or, worse, it may not work for all services without you realizing some were left vulnerable, such as web-based email, as well as possibly ceasing to work later if Plesk alters ssl.conf.

2) If you're using nginx, the script is modifying the template files in /usr/local/psa/admin/conf/templates/default/ which Parallels specifically warns should never be done because those files get replaced automatically by updates. The proper way to modify nginx on a Plesk server is to create a new /usr/local/psa/admin/conf/templates/custom directory and copy the templates needing modification into that directory, modify those copies, then run the httpdmng program to reconfigure. Not doing it that way will likely just result in sslv3 turning back on after the next update.

3) For postfix, in addition to smtpd_tls_mandatory_protocols, smtpd_tls_protocols and the three *_cipherlist directives should be set.

4) Courier should have the TLS_PROTOCOL directive updated to be set to "TLS1" not the default of "SSL3", in addition to the cipher changes they make, which are still not ideal because of #5 below.

5) In all cases, if they are even setting the cipher list, they are not setting it to a recommended cipher selection that prioritizes stream-based ciphers ahead of block-based ciphers, and, when the relevant daemon supports it, requires the cipher list be honored in order with the first compatible cipher. For example, while you can tell Apache to use a specific cipher list, if you don't also set "SSLHonorCipherOrder on", then a remote client that tries a block cipher by default, will keep using that even if you set the cipher list to prefer stream ciphers. With the SSLHonorCipherOrder set, it will use the server's preference instead.

This will soon become a non-issue for Chrome users, since Google is disabling SSLv3 and prioritizing stream ciphers, but other browsers are slower to adopt ssl best practices.

[skepticwebguy]

Re: Do We Need to Worry About PoodleBleed?

Thank you, David. I will discuss this with my web host. Ultimately, they recommend a server upgrade. But that's such a huge endeavour.

[ILoveHostasaurus]

Re: Do We Need to Worry About PoodleBleed?

With the exception of Plesk version 9 servers, it should be technically possible, and mostly easy, to disable SSLv3 and set the ciphers on all services on any version of Plesk and OS version, even the really old stuff. Plesk 9 uses a software called lighttpd for its port 8443 services that does not support the disabling of SSLv3 because of the version it uses.

[skepticwebguy]

Re: Do We Need to Worry About PoodleBleed?

With the exception of Plesk version 9 servers, it should be technically possible, and mostly easy, to disable SSLv3 and set the ciphers on all services on any version of Plesk and OS version, even the really old stuff. Plesk 9 uses a software called lighttpd for its port 8443 services that does not support the disabling of SSLv3 because of the version it uses.

I'm running Plesk 11.5.

[ILoveHostasaurus]

Re: Do We Need to Worry About PoodleBleed?

Should be no problem to have SSLv3 off and cipher order forced on any OS 11.5 will run on, so shouldn't need a server upgrade to reach an ideal config. We have 11.5 on CentOS 5 and 6.

[skepticwebguy]

Re: Do We Need to Worry About PoodleBleed?

Should be no problem to have SSLv3 off and cipher order forced on any OS 11.5 will run on, so shouldn't need a server upgrade to reach an ideal config. We have 11.5 on CentOS 5 and 6.

My server has CentOS 5 currently.

I suspect, I need to figure out how to modify ssl.con from within Plesk. Looking at /etc/httpd/conf.d/ssl.conf, these lines are commented out:

# SSL Engine Switch:
#SSLEngine on

#SSL Protocol support:
#SSLProtocol all -SSLv2

#SSL Cipher Suite:
#SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW

I'm not sure where to set cypher order.

In the newly created ssl_disablev3.conf, it says:

SSLProtocol all -SSLv2 -SSLv3

[ILoveHostasaurus]

Re: Do We Need to Worry About PoodleBleed?

The critical part is whether the following line is commented out or not commented out:

#<VirtualHost _default_:443>

or

<VirtualHost _default_:443>

If it is NOT commented out, then the following directives should be placed both before AND after it:

SSLProtocol all -SSLv2 -SSLv3

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

If it is commented out, then they only need to be in the file once.

That SSLCipherSuite line is a really long weird one, the important part is that what ends up in your ssl.conf remains as just one long line and doesn't get line broken into something weird like:

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:

or it will break the apache config.

[skepticwebguy]

Re: Do We Need to Worry About PoodleBleed?

I have:

#<VirtualHost _default_:443>

So, should the code you posted go before or after the line above?

[ILoveHostasaurus]

Re: Do We Need to Worry About PoodleBleed?

In it's current state, it won't matter, but I recommend putting it below it in case Plesk chooses to uncomment that line at some point.

[skepticwebguy]

Re: Do We Need to Worry About PoodleBleed?

Do I need restart Plesk and Apache, or run a command to reconfigure? I'm not sure what the reconfigure command would be.