Poodle SSLv3 vulnerability

I've done more digging and have updated the guide again:
http://help.directadmin.com/item.php?id=571

For DA, the ciphers only allow for TLSv1.2, so I've updated the binaries themselves to allow TLSv1, TLSv1.1 and TLSv1.2.
Note, even if you've got ssl_ciphers=SSLv3, the new binaries will still only allow TLS 1, 1.1, and 1.2.
They're in the pre-release area if anyone needs them.

Exim required me to actually dig into it's source code to figure out how to use the no_sslv3 option, but figured it out.

So with the new ciphers list, and the pre-release DA binaries, you can disable SSLv3, but still have all 3 TLS types.
If you don't get the new DA binaries, then you'd use the -SSLv3 cipher, which would then give you only TLSv1.2.. which isn't that bad anyway, since most browsers should support it.

John

Please note that upgrading the ciphers for DirectAdmin will break Mozilla Firefox. It looks like Firefox only supports TLS on port 443. Google Chrome and Internet Explorer work correctly but your customers might feel you are down.
 
If we update the OpenSSL RPM with TLS_FALLBACK_SCSV , then restart DirectAdmin panel.
Then, DirectAdmin panel shall also be not vulnerable to Poodle SSLv3 vulnerability . Am I right?
 
That's correct only for the cases where the client also supports it.
This is not always going to be the case, hence using either the new ciphers with old DA binaries (TLS1.2), or new DA binaries with old ciphers (TLS1, TLS1.1, TLS1.2), would be the solution.

John
 
appears my hosting company blocked my port 25 due to excessive spam
msg id [email protected]

i guess poodle was the culprit?
will updating my DA be enough to fix the exploit?
 
Please note that upgrading the ciphers for DirectAdmin will break Mozilla Firefox. It looks like Firefox only supports TLS on port 443. Google Chrome and Internet Explorer work correctly but your customers might feel you are down.

Can anyone else confirm this? John?

@John, when you release DirectAdmin 1.46.3, will that automatically disable SSLv3 in DirectAdmin controllpanel, or will it only happen if the server administrator make needed changes? We can't do this change until it is more tested. Could be it is not working in Firefox as user posted above.

Also I am running DirectAdmin multiserver, so it is bad if DirectAdmin disable SSLv3 automatically when we upgrade, because I can't upgrade all servers at the same time, I need few hours for each server, and with multiserver I think they can't communicate over https if SSLv3 is only disabled on one of the servers. So please don't disable it automatically when upgrading DirectAdmin, we need time to test and then apply the change ourself.
 
appears my hosting company blocked my port 25 due to excessive spam
msg id [email protected]

i guess poodle was the culprit?
That's extremely unlikely. There are lots of ways third parties can spam through your server that have nothing to do with the poodle. Including people stealing your password, guessing your password, vulnerabilities in websites, etc.

And For someone to be able to get into your sever through poodle they'd first need to intercept traffic between an authorized user with an authorized login, and your server (a man-in-the-middle attack) and then watch to see the login information pass.

So it's much more likely the spammers either have an email password or are using a compromised site. Check your email logs.
will updating my DA be enough to fix the exploit?
Not just DirectAdmin but also the other programs that use SSL. The next version of DirectAdmin (due for release today or tomorrow) should update DirectAdmin for you.

Note that updating without the new version of DirectAdmin will make it impossible for usres to log into DirectAdmin seucrely using Firefox. We recommended our users use Chrome until we installed the pre-release binaries. See my next post below.

Jeff
 
Can anyone else confirm this? John?

@John, when you release DirectAdmin 1.46.3, will that automatically disable SSLv3 in DirectAdmin controllpanel, or will it only happen if the server administrator make needed changes? We can't do this change until it is more tested. Could be it is not working in Firefox as user posted above.
I can answer the above because I've been working with John onunderstanding the issue and on testing the new binaries.

Making the fix announced by DirectAdmin staff for older versions of DirectAdmin will result in Firefox not being able to log in to DirectAdmin, but updating to the new version of DirectAdmin will by itself solve the problem with DirectAdmin (only), requiring no change to directadmin.conf), while allowing firefox and other browsers to work securely. Other daemons must still be patched for security.
Also I am running DirectAdmin multiserver, so it is bad if DirectAdmin disable SSLv3 automatically when we upgrade, because I can't upgrade all servers at the same time, I need few hours for each server, and with multiserver I think they can't communicate over https if SSLv3 is only disabled on one of the servers. So please don't disable it automatically when upgrading DirectAdmin, we need time to test and then apply the change ourself.
I don't use Multi-server Option so my answer is untested, but ...

The code in directadmin.conf remains exactly the same. Both before and after the update DirectAdmin servers should be able to talk to each other securely; the only difference is that they will talk only secure if DirectAdmin is updated.

I hope John will reply and verify.

Jeff
 
Getting rid of SSLv3 is nice, but CBC mode and SHA1 without PFS is just not good enough these days. DA really needs to fix the ssl_cipher variable.
 
Just to confirm, using something like this (same as Apache) would satisfy that?
Code:
ssl_cipher=HIGH:!aNULL:!MD5
If that works, I'll have DA swap ssl_cipher=SSLv3 to it during an update.

John
 
Just to confirm, using something like this (same as Apache) would satisfy that?
Code:
ssl_cipher=HIGH:!aNULL:!MD5
If that works, I'll have DA swap ssl_cipher=SSLv3 to it during an update.

John
Not if SHA1 and CBC modes are still allowed in HIGH.
But the problem is the cipher order. I want DA to use TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, so this comes first in my list, but DA doesn't listen and downgrades the connection.
 
Hmm... I'm not too sure about that. We just take the cipher list and pass it to the SSL_set_cipher_list() function.
When I try using *just* that one cipher on CentOS 6, 64-bit, eg:
Code:
ssl_cipher=TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
DA won't even start up:
Code:
[root@es6-64 directadmin]# ./directadmin
Error Loading ssl_cipher: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
Is that maybe a cipher that is part of the SSLv3 protocol that was disabled? (I'm not terribly familiar with specific ciphers).. if it's not a valid cipher, that may explain why it's being skippped.

John
 
Hmm... I'm not too sure about that. We just take the cipher list and pass it to the SSL_set_cipher_list() function.
When I try using *just* that one cipher on CentOS 6, 64-bit, eg:
Code:
ssl_cipher=TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
DA won't even start up:
Code:
[root@es6-64 directadmin]# ./directadmin
Error Loading ssl_cipher: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
Is that maybe a cipher that is part of the SSLv3 protocol that was disabled? (I'm not terribly familiar with specific ciphers).. if it's not a valid cipher, that may explain why it's being skippped.

John
Well, DA is the only server component not following the cipher order. Proftpd, exim, dovecot, Apache, NGINX all use PFS.

I should have given you a proper list. The one I gave you was what the browser was recognising.

Here is a list which should give you TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as the first cipher to use

Code:
EDH+aRSA:EECDH+aRSA:!SSLv3:!3DES:!RC4

Check out
https://www.openssl.org/docs/ssl/SSL_CTX_set_options.html
SSL_set_options()
SSL_OP_CIPHER_SERVER_PREFERENCE
When choosing a cipher, use the server's preferences instead of the client preferences. When not set, the SSL server will always follow the clients preferences. When set, the SSLv3/TLSv1 server will choose following its own preferences. Because of the different protocol, for SSLv2 the server will send its list of preferences to the client and the client chooses.
 
Last edited:
Perfect, thanks for the accurate information.
I've added SSL_OP_CIPHER_SERVER_PREFERENCE into the ssl options.

Uploading the pre-release binaries now, should be available within 10 minutes.

John
 
John,

Will updates to DirectAdmin automatically put the correct settings into directadmin.conf, or is this something we'll need to manage ourselves?

Thanks.

Jeff
 
For the next release, if your directadmin.conf has either:
Code:
ssl_cipher=SSLv3
ssl_cipher=ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-SSLv3:-EXP
DA will automatically convert it over to
Code:
ssl_cipher=HIGH:!aNULL:!MD5
And for future installs, the default directadmin.conf does not have any ssl_cipher listed, so it will always fall back to the internal deafult of
Code:
ssl_cipher=HIGH:!aNULL:!MD5
John
 
Perfect, thanks for the accurate information.
I've added SSL_OP_CIPHER_SERVER_PREFERENCE into the ssl options.

Uploading the pre-release binaries now, should be available within 10 minutes.

John
Just tested it and it's not quite working properly, but I think it's because you only support TLS1.0 and not TLS 1.2 which has all the best ciphers.

I'm limited to SHA1 which is not good enough these days, even if DA servers don't store national secrets :)
 
I'm limited to SHA1 which is not good enough these days, even if DA servers don't store national secrets :)

Just a follow up on this with a link from Google and a quote: http://googleonlinesecurity.blogspot.no/2014/09/gradually-sunsetting-sha-1.html

That’s why Chrome will start the process of sunsetting SHA-1 (as used in certificate signatures for HTTPS) with Chrome 39 in November. HTTPS sites whose certificate chains use SHA-1 and are valid past 1 January 2017 will no longer appear to be fully trustworthy in Chrome’s user interface.

So this is getting more and more urgent. Edit: Also see http://www.webhostingtalk.com/showthread.php?t=1427518
 
Last edited:
Just tested it and it's not quite working properly, but I think it's because you only support TLS1.0 and not TLS 1.2 which has all the best ciphers.

I'm limited to SHA1 which is not good enough these days, even if DA servers don't store national secrets :)
Erm.. not sure I'm following you on this comment.
DA works fine with TLS 1.2, if openssl supports it.
I've just tested the latest pre-release binaries with the following cipher:
Code:
ssl_cipher=HIGH:!aNULL:!MD5
and it's using TLS 1.2 in chrome (CentOS 6, 64-bit)

I just tested on CentOS 5, with the latest yum update of openssl, and full DA source recompile, and indeed, it was using TLS 1.0.
However, the same is said for Apache/https with CentOS 5.. it was using TLS 1.0, and not TLS 1.2..
so I believe that CentOS 5 simply doesn't support TLS 1.2, but CentOS 6 does.

John
 
Back
Top