Draft: Add SNI routing support for MySQL

[NoOverflow]

What does this PR do?

This PR aims to add support for L4 Routing for MySQL using SNI.

Motivation

For a while Traefik could not route TCP (w/ TLS) requests for MySQL as both the client and server did not support SNI. The only option was to use a wildcard router ('HostSNI(*') which works fine, until you need enable TLS to host multiple MySQL instances using the same entrypoint on Traefik.

This has since been addressed by MySQL and SNI support has been added as of version 8.1.0 (2023/07)

Adding routing for MySQL would allow multiple databases to be behind a single Traefik instance.

Draft issues

• Fake handshake packet
• Figure out how to send a proper handshake packet, as there may be multiple MySQL instances using different configuration values, we can't just send fake values, we also cannot get them from the right server since we don't know at this point which one the client is trying to reach.
• Find a proper way to identify a MySQL connection, since it uses a client-first protocol. (An example of fingerprinting for Postgresql)

More

• Fix Draft issues (see above)
• Added/updated documentation

Additional Notes

Useful links

• https://dev.mysql.com/doc/dev/mysql-server/latest/page_protocol_basic_tls.html
• https://dev.mysql.com/doc/dev/mysql-server/latest/page_protocol_connection_phase_packets_protocol_handshake.html
• https://dev.mysql.com/doc/dev/mysql-server/latest/page_protocol_connection_phase_packets_protocol_ssl_request.html
• https://dev.mysql.com/doc/dev/mysql-server/latest/page_protocol_connection_phase.html

Closes #10505

[nmengin]

Hey @NoOverflow,

Thank you for your contribution.
Could you tell us when your PR will be in a status that allow us to start our review?

Thanks in advance.

[NoOverflow]

Hey @nmengin,
I wish I could tell you, there are still many problems that need to be fixed. I opened this PR to basically kickstart the work for MySQL support (see #10505 (comment))

[Kwuray]

Hello,

Is it really a problem to send a fake initial handshake packet?

We could test each server flag capability and measure the impact of sending a false value?
For example, the predominant encoding is that of the client, and sending a false value does not seem very problematic.

https://dev.mysql.com/doc/refman/8.4/en/charset-connection.html#charset-connection-error-handling

It appears that it is impossible to determine the SNI before sending the initial handshake packet, or even resend it later for correction.

[Kwuray]

Hi @NoOverflow

How can I suggest changes? For example to check that it is an SSL request : // TODO: Parse the response and check if the client requested SSL instead of manually checking the username byte

Can I push directly into your fork?
I have never participated in open source projects...

Thanks

[NoOverflow]

Hello,

Is it really a problem to send a fake initial handshake packet?

We could test each server flag capability and measure the impact of sending a false value? For example, the predominant encoding is that of the client, and sending a false value does not seem very problematic.

https://dev.mysql.com/doc/refman/8.4/en/charset-connection.html#charset-connection-error-handling

It appears that it is impossible to determine the SNI before sending the initial handshake packet, or even resend it later for correction.

Hi @Kwuray, this is a question that needs answering, maybe it will break or not, there are many edge cases to test

Hi @NoOverflow

How can I suggest changes? For example to check that it is an SSL request : // TODO: Parse the response and check if the client requested SSL instead of manually checking the username byte

Can I push directly into your fork? I have never participated in open source projects...

Thanks

You're free to open a PR on my repo targeting the NoOverflow:feat-mysql-support-v3.0 branch 😄

[umeshkhatiwada1]

so Any update regarding the PR @NoOverflow

[GMProg]

Hey, I've also run into this, as I see it there is not a fine and nice solution, (other than waiting for the change of mysql protocol), but what if we had options when defining the entrypoint that it is a server-first entrypoint and also the protocol, so when receiving a packet on that port we would know what to do with it.
I know this also has it's limitations, like one type of portocol/port, but I think this is better than the current one service/port situation, and not to mention this solution would set the base of other server-first protocols.

@nmengin What do you think, would this type of solution be acceptable by traefik's end?

[Kwuray]

@GMProg with your solution we would do the same thing with the request regardless the MySQL service ? So impossible to have various MySQL server (different Charest, version, ...) ? Maybe I did not understand your idea 😅

[GMProg]

@GMProg with your solution we would do the same thing with the request regardless the MySQL service ? So impossible to have various MySQL server (different Charest, version, ...) ? Maybe I did not understand your idea 😅

well yes, my suggestion would mean that all mysql servers should have the same configuration, at least to the level that's sent by the server first, and also there's the connection id parameter, which is just, really hard to fake, you're right this not the way either, sadly.

[NoOverflow]

@GMProg You could indeed do that, but as @Kwuray correctly mentioned, you would be stuck with a single version of MySQL behind your traefik instance since MySQL is a server-first protocol and the first packet (even before STARTTLS negotiation) contain server properties that you cannot "get" as you don't know where the request is heading to yet.

This port-based logic with a forged initial packet would help in (very) specific cases but would not make it into an official Traefik release.

The only way to progress further with this PR is to initiate a talk with the MySQL maintainers and propose a new protocol that would allow SNI routing (way easier said than done though...)

[nmengin]

Hello @NoOverflow,

@nmengin What do you think, would this type of solution be acceptable by traefik's end?

We have discussed with the other maintainers the opportunity to dedicate an entrypoint to the mysql protocol.
And... We haven't reached any consensus on it!

Even if the proposition is interesting, some maintainers would prefer to manage this mechanism globally.
For this reason, we'd prefer not to go this way until more discussion on this topic.

[kevinpollet]

Hi @NoOverflow,

We discussed this issue during our triage session, and as mentioned in the previous message, we would like to address this globally, for example by having dedicated entry points. This would allow us to support other protocols without having to have assertions in the connection path to detect them, which can get tricky at some point and introduce incompatibilities.

And as you said, even with dedicated entry points, this may not be possible today.

So we are closing this pull request.