In my previous blogs I told you to enable SSL/TLS and configure it to check the CA. So I followed my advice and did all that. Great! So the --ssl-mode setting was used a few times as a solution. And it has a setting we didn't use yet: VERIFY_IDENTITY . In older MySQL versions you can use --ssl-verify-server-cert . Both turn on hostname verification. The attack Get any certificate which is trusted by the configured CA, this can for example be a certificate from a development machine. And use that with a man-in-the-middle proxy. Then the client: Checks if SSL is uses ( --ssl-mode=REQUIRED ) Verify if the certificate is signed by a trusted CA ( --ssl-mode=VERIFY_CA ) Both checks succeed. But the certificate might be for testhost01.example.com and the database server might be prod-websitedb-123.example.com. Browsers by default verify hostnames, MySQL does not. Turning on hostname validation So use --ssl-mode=VERIFY_IDENTITY and everything should be fine? Well that might ...

In my previous blogs I told you to enable SSL/TLS and force the connection to be secured. So I followed my advice and did forced SSL. Great! So now everything is 100% secure isn't it? No it isn't and I would never claim anything to be 100% secure. There are important differences in the SSL/TLS implementations of browers and the implementation in MySQL. One of these differences is that your browser has a trust store with a large set of trusted certificate authorities. If the website you visit has SSL enabled then your browser will check if the certificate it presents is signed by a trusted CA. MySQL doesn't use a list of trusted CA's, and this makes sense for many setups. The key difference is that a website has clients (browsers) which are not managed by the same organization. And for MySQL connections the set of clients is often much smaller are more or less managed by one organization. Adding a CA for a set of MySQL connections if ok, adding a CA for groups of web...

Intro In my previous blog post I told you to use SSL/TLS to secure your MySQL network connections. So I followed my advice and did enable SSL. Great! So first let's quickly verify that everything is working. So you enabled SSL with mysql_ssl_rsa_setup , used a OpenSSL based build or put ssl-cert , ssl-key and ssl-ca in the mysqld section of your /etc/my.cnf and now show global variables like 'have_SSL'; returns 'YES'. And you have configured the client with --ssl-mode=PREFERRED . Now show global status like 'Ssl_cipher'; indicates the session is indeed secured. You could also dump traffic and it looks 'encrypted' (i.e. not readable)... With SSL enabled everything should be safe isn't it? The handshake which MySQL uses always starts unsecured and is upgraded to secured if both the client and server have the SSL flag set. This is very similar to STARTTLS as used in the SMTP protocol. To attach this we need an active attack; we need ...

Intro In a set of blog posts I will explain to you how different attacks on the network traffic of MySQL look like and what you can do to secure your systems againt these kinds of attacks. How to gain access To gain access to MySQL network traffic you can use tcpdump, dumpcap, snoop or whatever the tool to capture network packets on your OS is. This can be on any device which is part of the connnection: the server, the client, routers, switches, etc. Besides application-to-database traffic this attack can also be done on replication traffic. Results This allows you to extract queries and result sets. The default password hash type mysql_new_password uses a nonce to protect against password sniffing. But when you change a password this will be sent accross the wire by default. Note that MySQL 5.6 and newer has some protection which ensures passwords are not sent to the logfiles, but this feature won't secure your network traffic. In the replication stream however there are...

Running out of disk space is something which, of course, should never happen as we all setup monitoring and alerting and only run well behaved applications. But when it does happen we want things to fail gracefully. So what happens when mysqld runs out of disk space? The answer is: It depends It might start to wait until disk space becomes available. It might crash intentionally after a 'long semaphore wait' It might return an error to the client (e.g. 'table full') It might skip writing to the binlog (see binlog_error_action ) What actually happens might depend on the filesystem and OS. Fixing the disk space issue can be done by adding more space or cleaning up some space. The later can often be done without help of the administrator of the system. So I wanted to change the behaviour so that it MySQL wouldn't crash or stop to respond to read queries. And to also make it possible for a user of the system to cleanup data to get back to a normal state. ...