MySQL 5.7 makes secure connections easier with streamlined key generation for both MySQL Community and MySQL Enterprise, improves security by expanding support for TLSv1.1 and TLSv1.2, and helps administrators assess whether clients are connecting securely or not with new visibility into connection types.  Extending this emphasis on secure connections, MySQL Server 5.7 introduces a new server-side configuration option allowing MySQL administrators the ability to restrict connections to clients who use secure transport.  The blog post will examine this new configuration option and demonstrate its usage.

What is “secure”?

When talking about requiring secure transport, the first question to answer is what should be considered “secure”?  In my earlier blog post on identifying secure connections, I identified the following three transports used by MySQL as secure:

• SSL/TLS
• Socket
• Shared Memory

Of particular note, connections on Windows machines using the named pipe transport are not considered secure – while such connections are typically made locally, named pipe connections can be made remotely, and lack data encryption to protect payloads sent over the wire.

–require_secure_transport

In MySQL Server 5.7.8, the --require_secure_transport configuration option was added (WorkLog#7709).  This boolean option defaults to OFF, meaning connections using any of the supported protocols are accepted – consistent with legacy behavior.  Setting --require_secure_transport=ON causes the server to reject new connections which do not use one of the three connection types listed above.  Clients rejected due to insecure connections receive the following new error:

D:\mysql-advanced-5.7.10-winx64>bin\mysql -uroot -P3310 --skip-ssl
ERROR 3159 (HY000): Connections using insecure transport are prohibited while 
--require_secure_transport=ON.

Interaction with account-level requirements

MySQL has long supported requiring TLS for specific accounts – this is accomplished by including the REQUIRE SSL clause in CREATE or ALTER USER commands.  The new --require_secure_transport option compliments these account-level requirements by enforcing secure transport at a global level.  A notable difference is that account-level restrictions can be met only by TLS connections, while the global restriction considers the three secure protocols adequate.  As a result, a user defined with REQUIRE SSL connecting to a server where --require_secure_transport=ON will be rejected if TLS is not used – even if the transport is one of the three identified secure protocols.  Likewise, when --require_secure_transport=OFF, the requirement for TLS connection for the same user will not be relaxed.

Conclusion

This new configuration option gives MySQL DBAs the ability to more easily lock down MySQL deployments and demand that any connections leverage secure transport.  Allowing Socket or Shared Memory connections allows high-performance same-host connections while restricting remote access to clients leveraging TLS-secured protocol.  In environments where accounts are created dynamically, a global server-side option to demand secure transport can be significantly easier to manage than account-level TLS requirements.