If all of your MySQL SSL clients just broke...

6/5/2015

EDIT: It looks like RedHat pushed a new build that fixes the issue ->
https://rhn.redhat.com/errata/RHBA-2015-1129.html

If all of your MYSQL SSL clients and replication just broke, I'm guessing that you're running RedHat, CentOS, or something derived from RedHat. In short, RH modified OpenSSL to reject Diffie Hellman (DH) keysizes less than 768 bits. Note that this is not the length of your private key. This is the DH key which is used in Perfect Forward Secrecy.

Someone please correct me if I'm wrong, but selecting which PFS ring (and hence keysize) to use is a function of the application making the SSL socket request. Therefore, you'll need an updated version of Percona or MySQL community to fix this with PFS ciphers.

One option is to use a secure, symmetric cipher in your configs. We went this route to keep things going. On CentOS 6, one of the best choices is Camellia 128. If you're doing command line work, add this to the argument list:

You should also be able to add that to your my.cnf and get things going that way, too.

The error thrown in MySQL is error 2026, which is a catch-all for all SSL errors. It throws that error for bad certs, bad permissions, bad anything....which makes things difficult to track down. That said, if things broke in the past few days (June 4th), it's probably the cipher problem. We tracked it down in the yum log (openssl-1.0.1e-30.el6.9.x86_64). Whenever something suddenly stops working, always check the yum log first. Thanks RedHat!

David Young link

6/7/2015 12:04:12 pm

Note that if you're editing my.cnf, the cipher seems to be case-sensitive (unsure about CLI invocation). I had to use:
ssl-cipher=CAMELLIA128-SHA

diq link

6/14/2015 06:02:37 am

Good catch David! I've corrected the post.

Jim Albert

6/15/2015 04:46:06 am

You could also disable Diffie Hellman key exchange by adding :-DH:-ECDH to the end of your ssl-cipher config in your my.cnf. Although I believe you then give up forward secrecy in exchange for using a different key exchange method. Ideally, this is fixed in mysql soon so we should watch for that fix and then go back and remove these ssl-cipher config crutches.

John Smith link

6/17/2015 08:21:41 am

We were bitten by this recently in our php based web application. The solution (since we were using PDO DB connections) was to build our connections like this:
<?php
$pdo = new PDO(
'mysql:host=hostname;dbname=ssldb',
'username',
'password',
array(
PDO::MYSQL_ATTR_SSL_KEY =>'/path/to/client-key.pem',
PDO::MYSQL_ATTR_SSL_CERT=>'/path/to/client-cert.pem',
PDO::MYSQL_ATTR_SSL_CA =>'/path/to/ca-cert.pem',
PDO::MYSQL_ATTR_SSL_CIPHER => 'CAMELLIA128-SHA',
)
);
?>

Works like a charm, thanks for pointing me in the right direction!

R Feroze

6/17/2015 09:58:04 pm

We have a django application that connects to a remote MySQL server over SSL. Until this upgrade to OpenSSL, the connection to mysql worked well. Now it does not because ssl_cipher is not a valid option for mysql.connector.django, the python3 driver I use for communicating with mysql.

Does anyone else have a similar problem ?

Here is the output from httpd ssl_error_log:
..../lib/python3.4/site-packages/mysql/connector/connection.py", line 195, in _do_auth
self._socket.switch_to_ssl(**ssl_options)
TypeError: switch_to_ssl() got an unexpected keyword argument 'cipher'

6/17/2015 10:21:33 pm

For python, you can use the 'options_file' connection argument to include your my.cnf file, and 'option_groups' argument to specify the '[client]' section. Then just edit your my.cnf (as stated by David Young above) and add 'ssl-cipher=CAMELLIA128-SHA' to the [client] section of my.cnf.

6/18/2015 11:20:43 am

Thanks for that John. Using the options file did not fix the problem completely. It turns out ciphers value set in my.cnf is not used by the mysql.connector.django.

Here is a workaround for those in a similar situation, please edit file ...lib/python3.4/site-packages/mysql/connector/network.py and append ciphers='CAMELLIA128-SHA' to ssl.wrap_socket() call in the switch_to_ssl() method.

Here is the code to change :
self.sock = ssl.wrap_socket(
self.sock, keyfile=key, certfile=cert, ca_certs=ca,
cert_reqs=cert_reqs, do_handshake_on_connect=False,
ssl_version=ssl.PROTOCOL_TLSv1, ciphers='CAMELLIA128-SHA')

A question, is there a way to use SSLContext.set_ciphers(ciphers) method instead of the above hack. If so how ?

6/18/2015 11:32:46 am

Forgot to include versions of packages I am using
Django==1.7.4
mysql-connector-python==2.0.3

6/23/2015 03:57:13 am

Looks like RedHat released a new build of MySQL that fixes the DH issue: https://rhn.redhat.com/errata/RHBA-2015-1129.html

6/23/2015 12:56:33 pm

Yes... I just updated for CentOS6 as well and looks to be fixed.

Onlime Webhosting link

7/1/2015 01:12:59 am

Thanks for this great post. Percona just released Percona-Server 5.6.25-73.0 today which fixes this issue. Tested and confirmed working! See changelog:

- RHEL/CentOS 6.6 OpenSSL package (1.0.1e-30.el6_6.9), containing a fix for CVE-2015-4000, changed the DH key sizes to a minimum of 768 bits. This caused an issue for MySQL as it uses 512 bit keys. Fixed by backporting an upstream 5.7 fix that increases the key size to 2048 bits. Bug fixed #1462856 (upstream #77275).

https://www.percona.com/blog/2015/07/01/percona-server-5-6-25-73-0-is-now-available/

Comments are closed.

If all of your MySQL SSL clients just broke...

Author

Archives

Categories