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.
What types of products are dependent upon access to unencrypted protocol data? Most immediately apparent are proxy-based and network capture-based products. Proxy-based products typically rely on the same characteristics which can make the MySQL client/server network protocol an attractive target – direct access to unencrypted data. These and other products which rely on non-encrypted data streams will need to account for higher probability that the data collection mechanism upon which they depend will become unavailable as TLS connections become more common. It’s easy to test whether or not a product works with TLS connections today.
Beyond supporting a minimal TLS configuration, such products will want to consider how to deploy in a truly hardened environment. A comprehensive TLS deployment will not only encrypt data on the network, but also provide guarantees that the conversation between the client and server isn’t being funneled through an intermediary process. That’s exactly what a proxy is – it sits between the client and server, and this makes securing connections in such deployments more complex. By adding a proxy process to the communication, you are explicitly expanding trust boundaries to include the proxy process. The server and client each can only know that they are communicating with the proxy – each knows nothing about the actual conversation endpoint. Each will need to establish trust and identity for their segment of the conversation – client to proxy and proxy to server – and that means private keys and public certificates on each node (client, proxy, server). Obviously, the more parties added to the network conversation adds non-trivial configuration complexities in setting up a secure connection.
Proxy-based products will also want to consider the performance impact of TLS-secured connections. The proxy will need to decrypt inbound network packets, perform any transformation or processing, re-encrypt and send to the appropriate recipient. In a hardened deployment, this will typically involve managing two different encryption keys for each segment of the conversation (one for the client side, one for the server side), so it’s not feasible to simply pass along the received encrypted packet and defer processing.
This post should not be interpreted as an indictment of proxy-based approaches – we’ve used this as a lowest-common-denominator solution in the past where we couldn’t quickly add needed features to the core products in which they are more ideally implemented. The query analysis feature of MySQL Enterprise Monitor is a great example of this – we leveraged MySQL Proxy to collect query data before we could provide collection services in our connectors (and to provide support for those connectors which we don’t directly maintain). Over time, query analysis data collection has migrated to the connectors themselves and the server (via PERFORMANCE_SCHEMA), where it belongs, performs better, and can expose much richer data (such as application stack traces, or server internal diagnostics). Likewise, load-balancing and HA solutions (even if they only balance on connection creation, and don’t care about packet contents) should validate that functionality is retained with TLS connections.
That said, proxy-based products have unique challenges relative to both security and performance, and developers and users of these products will need to carefully assess how these products may be affected by an increased usage of TLS.