Restricting Connections to Secure Transport

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:

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.

3 thoughts on “Restricting Connections to Secure Transport

    1. Hi Wlad,

      You’re question is really about trust boundaries, and in this model, a nefarious user with access to install/run nefarious programs accessing shared memory on the database server itself is already operating inside the trust boundaries. Because we’re talking about only a small percentage of MySQL deployments (Windows users who explicitly enable shared memory connections), this is largely hypothetical – but the concept applies to other deployments as well. I’m reasonably confident socket transport on Linux can also be intercepted by a privileged local user. Secure connections rely on secure transport and trusted endpoints. Even TLS connections can be undermined when the endpoints are unknown/not verified, or compromised.

      1. I think what makes shared memory different from socket is that it can be read and written without any privileges. I mean – the hardest part is guessing the name of the mapping (one can try many variations), the rest – mapping file into memory and reading memory – is trivial.

        Yes, it is right the potential attacker has to be local, but it neither has to be privileged, or know the password. I’d think long before declaring shared memory connection “secure” 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

Please enter *