Support for secure connections (TLS)

[luislavena]

Hello!

First want to thank you for working on the native protocol. I've compared the new version of the adapter against the old libmysql one and had incredible speedup on our scripted tasks! :smile:

However, noticed that due the migration to native protocol, we lost the ability to use a secure connection (was hacky then, now not possible), which is essential when establishing connections between our app and the DB provider across regions when no VPN can be established (for example, when using Compose).

Was wondering if there are plans to integrate such support in the future?

Thank you in advance for your time :heart: :heart: :heart:

[bcardiff]

@luislavena it's doable i think. Right now we only set up a TCPSocket here.

I was also willing to add a mysql:///tmp/mysql.sock for file socket connections, so definitely we need more connection options here.

What about mysql://root@localhost/test?ssl_mode=required as a connection string with ssl required?

Eventually it would be good to support CA as in [net/connector]:(https://dev.mysql.com/doc/connector-net/en/connector-net-connection-options.html) for example:

• None / Disabled - do not use SSL.
• Preferred - use SSL if the server supports it, but allow connection in all cases.
• Required - Always use SSL. Deny connection if server does not support SSL.
• VerifyCA - Always use SSL. Validate the CA but tolerate name mismatch.
• VerifyFull - Always use SSL. Fail if the host name is not correct.

Would be enough to have the ssl options disabled and required for your usage?

---

[updated: to match mysql2 ssl option names as suggested by @spalladino]

[spalladino]

Just a detail: I'd follow the same naming conventions as the ubiquitous Ruby mysql2 adapter, which uses ssl_mode instead of just ssl. See here for all the options.

[asterite]

Another note: in the standard library we began using tls everywhere, because ssl is kind of an old name now, though I'm not sure it's applicable here.

[luislavena]

in the standard library we began using tls everywhere, because ssl is kind of an old name now

That is one of the reasons I mentioned in the title TLS instead of SSL, even when MySQL documentation says SSL :smile:

Just a detail: I'd follow the same naming conventions as the ubiquitous Ruby mysql2 adapter.

Bear with me for a minute: SSL moniker is used extensively across many libraries in Ruby (Puma, MySQL2 adapter, Thin, Faraday, etc)

But contrary to Ruby, Crystal don't carry that legacy name and weight of time on this option, as is shown by the usage of tls on the standard library (both HTTP server and client).

On the same line, PostgreSQL also refers to SSL for secure connections, but, like MySQL, there is a legacy baggage carried around.

Now, Go for example uses tls in the MySQL adapter but ssl on the PostgreSQL one, so there is no consistency there.

I think there is a chance for us to unify such approach under the same convention so other SQL DB adapters follow the same approach.

Just some thoughts to keep the conversation going :smiley:

Either way, thank you for your attention and time answering this. :heart: :heart: :heart:

[kustom666]

Any updates on this? It would be very handy to have SSL enabled for cloud options (RDS comes to mind).

[da1nerd]

This would be a nice feature to have.

[da1nerd]

I started experimenting with this, gave up, and then started again. Here's a branch of my code https://github.com/da1nerd/crystal-mysql/tree/ssl

So far I think the initial MySQL handshake is properly implemented. The remaining piece is to figure out how to negotiate the SSL connection. I pasted in the implementation from the postgres driver, but it's not working yet.

For reference, the MySQL protocal is very well defined here https://dev.mysql.com/doc/internals/en/ssl.html

[da1nerd]

If someone wanted to help with this I'd be willing to pay a bounty of $100 :dollar: .