[sr-dev] running out of mysql connections when [group] is given

[Olle E. Johansson]

On 23 Jan 2015, at 03:58, Juha Heinanen <jh at tutpro.com> wrote:

> - why ssl is not used when i add ssl options to [client] instead of
>  [group]?
That is indeed strange.

I've started labbing a bit with this. I did not get the client to connect
with SSL unless I added ssl-cipher to the client like this

/usr/local/mysql/bin/mysql -h 127.0.0.1  -P 63306 --ssl --ssl-cipher=DHE-RSA-AES256-SHA:AES128-SHA << EOF
SHOW STATUS LIKE 'Ssl_cipher';
EOF

The default for Mysql - even if you have the --ssl option is no ssl. 

There's no way to really test the SSL configuration with common tools, since Mysql adds a few packets 
in front of the SSL negotiation. The server indicates SSL support and then the client
starts SSL.
http://dev.mysql.com/doc/internals/en/connection-phase-packets.html#packet-Protocol::SSLRequest

This opens up for a downgrade attack, much like STARTSSL in SMTP.

There's also no setting for version of SSL/TLS you want to use, only a CIPHER setting.

Mysql and/or MariaDB really needs to take this seriously and change their way of handling TLS.
The current implementation indicates that they needed a check-box option, but it was a long
time ago and haven't been updated since.

There is an overhead, which is propably why many people don't use it (apart from the weird
configuration). This presentation has some numbers.

http://www.yassl.com/files/yassl_securing_mysql.pdf

We can move the MySQL TLS settings into the db_mysql module, it seems like there are API calls for
it. If so, the db_mysql module could perform the query above and verify that SSL is active.
Right now, I would put a query using SQLOPS like you showed in an earlier mail in htable::mod-init event route
and disable the server if I got the wrong answer.

/O