Transport Layer Security (TLS, also often referred to as SSL) is an important component of a secure MySQL deployment, but the complexities of properly generating the necessary key material and configuring the server dissuaded many users from completing this task. MySQL Server 5.7 simplifies this task for both Enterprise and Community users. Previous blog posts have detailed the changes supporting Enterprise builds; this blog post will focus on parallel improvements made to MySQL Community builds.
MySQL Connector/Java 5.1.38 was released earlier this week, and it includes a notable improvement related to secure connections. Here’s how the change log describes it:
When connecting to a MySQL server 5.7 instance that supports TLS, Connector/J now prefers a TLS over a plain TCP connection.
This mirrors changes made in 5.7 to the behavior of MySQL command-line clients and libmysql client library. Coupled with the streamlined/automatic generation of TLS key material to ensure TLS availability in MySQL Server 5.7 deployments, this is an important step towards providing secure communication in default deployments. Continue reading Secure Java Connections by Default
Secure communications is a core component of a robust security policy, and MySQL Server 5.7.10 – the first maintenance release of MySQL Server 5.7 – introduces needed improvements in this area. Support for TLS has been expanded from TLSv1.0 to include TLSv1.1 and TLSv1.2, default ciphers have been updated, and controls have been implemented allowing both server and client-side configuration of acceptable TLS protocol versions. This blog post will describe the changes, the context in which these changes were made, note important differences in capabilities between Community and Enterprise versions, and outline future plans. Continue reading SSL/TLS Improvements in MySQL 5.7.10
Over the years, MySQL has used three different mechanisms for securing passwords both for storage and for transmission across networks. This blog post aims to provide a brief history of the various mechanisms and highlight reasons to migrate accounts to use the sha256_password mechanism introduced in MySQL Server 5.6. Continue reading Protecting MySQL passwords with sha256_password plugin
Today, oCERT published advisory 2015-003 describing a TLS vulnerability in MySQL and derivative products. The content isn’t exactly news – it is documented legacy behavior and the subject of an earlier blog post describing how MySQL Server 5.7 solves the problem. That said, the efforts of Duo Security are certainly appreciated and welcomed – it provides a meaningful context to discuss how to properly harden existing MySQL 5.5 and 5.6 deployments, as well as frame a discussion on potential changes in these versions to increase security.
As I wrote earlier, we want the default experience in MySQL 5.7 to be secure by default. Part of this includes securing connections by automatically creating key material and using TLS for connections where possible. This may have some significant implications for third-party software – especially products which depend upon capturing, evaluating and/or redirecting client/server traffic at the network level. This blog post is intended to highlight for developers and users of such products potential issues they may want to consider or address during the pre-GA period for MySQL Server 5.7. Continue reading Implications of TLS plans for third-party products
MySQL 5.7 aims to be the most secure MySQL Server release ever, and that means some significant changes in SSL/TLS. This post aims to tie together individual enhancements introduced over the span of several Development Milestone Releases (DMRs) into the larger initiative. In the simplest terms, we hope to have a minimal TLS configuration enabled by default, and for connections to prefer TLS by default. Let’s dig into the various aspects of this:
Joro wrote recently about MySQL 5.6.17‘s new support for AES-256 encryption, and it’s a great improvement for people need to encrypt their data at rest. The new session block_encryption_mode variable controls what variant of AES is used, and for backwards compatibility, the default behavior remains 128-bit key length with ECB block cipher mode. If you’re happy with that level of encryption, nothing changes – your existing code will work the same on 5.6.17 as it has on earlier versions (note that users of statement-based replication will experience new warnings). There are good examples of how to use the new functionality in the updated public test cases, but this blog post is intended to help orient users to the new options as well.