The POODLE Attack – SSL 3.0 Protocol Vulnerability (CVE-2014-3566)

Systems Affected

All systems and applications utilizing the Secure Socket Layer (SSL) 3.0 with cipher-block chaining (CBC) mode ciphers may be vulnerable. However, the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack demonstrates this vulnerability using web browsers and web servers, which is one of the most likely exploitation scenarios.



There is currently no fix for the vulnerability SSL 3.0 itself, as the issue is fundamental to the protocol; however, disabling SSL 3.0 support in system/application configurations is the most viable solution currently available.


** Updates available: RHEL/CentOS/RPM based OS:

yum -y update openssl

** You MUST disable SSLv3 in all used services (httpd, mail, etc) , The update just prevents the downgrading but the protocol itself is still vulnerable.

Setting up DA with an SSL certificate

You can switch DirectAdmin to use SSL instead of plain text. -> https instead of http on port 2222.
Note that this is for the DirectAdmin connection on port 2222, *not* for apache.
If you’re tryting to setup a certificate for your domain through apache, use this guide.

If you do not have your own certificates, you’ll need to create your own:/usr/bin/openssl req -x509 -newkey rsa:2048 -keyout /usr/local/directadmin/conf/cakey.pem -out /usr/local/directadmin/conf/cacert.pem -days 9000 -nodes

chown diradmin:diradmin /usr/local/directadmin/conf/cakey.pem
chmod 400 /usr/local/directadmin/conf/cakey.pem

This is the old method, use either the one above, or this one.  The end result is the same, but takes more steps.
openssl req -new -x509 -keyout /usr/local/directadmin/conf/cakey.pem.tmp -out /usr/local/directadmin/conf/cacert.pem -days 3653

openssl rsa -in /usr/local/directadmin/conf/cakey.pem.tmp -out /usr/local/directadmin/conf/cakey.pem

rm -f /usr/local/directadmin/conf/cakey.pem.tmp
chown diradmin:diradmin /usr/local/directadmin/conf/cakey.pem
chmod 400 /usr/local/directadmin/conf/cakey.pem

(Paste these one at a time as the first 2 require user input)

If you already have your own certificate and key, then paste them into the following files:

certificate:  /usr/local/directadmin/conf/cacert.pem
key: /usr/local/directadmin/conf/cakey.pem

Edit the /usr/local/directadmin/conf/directadmin.conf and set SSL=1  (default is 0).  This tells DA to load the certificate and key and to use an SSL connection.
Ensure your directadmin.conf has the values set:cacert=/usr/local/directadmin/conf/cacert.pem

but can be changed as needed.

DirectAdmin needs to be restarted after any changes to the directadmin.conf.

If you also have a CA Root Certificate, this can be specified by adding:carootcert=/usr/local/directadmin/conf/carootcert.pem

into the /usr/local/directadmin/conf/directadmin.conf file (won’t exist by default) and by pasting the contents of the caroot cert into that file.

Note, as of 1.30.2, you can set the value of the SSL redirect should a User connect to an https connection with plaintext http.

For 1.33.0, you can force DA to redirect to a specific hostname if you wish the host to match the cert installed:
However, if they connect to https on a different host, they’ll first get the ssl warning (since ssl is established before the host is passed), then they’ll be redirected to the correct host, where the error would not appear (assuming you’ve got a valid cert setup)

As of 1.33.3, you can enable a ssl cipher to force SSLv3, and disable SSLv2:

Why do I need an owned IP for my own SSL certificate?

The reason you must have your own dedicated IP address when you want to use your own SSL certificate (when you don’t want the server wide shared certificate) is because of the way SSL and Apache (httpd) works.

For name based web-hosting (when many domains are on one IP) the web browser will pass the name of the domain being requested inside the httpd headers along with the request.  This way, Apache knows which domain you are trying to access even though there are many domains on that one IP address.

When you do the same thing through an SSL connection, the connection has to be made *before* the request can be sent.  In this connection, the certificate is passed.  The only information that Apache knows before the request is made is which IP the connection is being made to.  It has to be able to know which certificate to send before the request is made, thus you can’t use multiple certificates on the same IP (if you do, Apache will use the first certificate listed which DA will always set to the server shared certificate for shared IPs).

If you want to use your own certificate, it must be the first certificate listed.  This wouldn’t work for a shared IP, because there would multiple domain wanting this status, and the first certificate would the one shown.  For this reason the shared certificate is always used on a shared IP.  For your certificate, DA will acknowledge the IP as being ‘owned’ and will remove the server shared certificate as the first cert to be loaded, thus your certificate will be loaded instead.