MySQL 5.7 makes secure connections easier with streamlined key generation for both and , improves security by expanding , and helps administrators assess whether clients are connecting securely or not with . 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.
When talking about requiring secure transport, the first question to answer is what should be considered “secure”? In my earlier blog post on , I identified the following three transports used by MySQL as secure:
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.
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.