Support for TLS 1.3 and 0-RTT

[MrMage]

Connecting from GKE to my Cloud SQL instance in the same zone takes about 15-25ms, adding to the latency of my web service.

With TLS 1.3 and zero-roundtrip resume, I hope that it would be possible to substantially reduce this delay.

See e.g. for a real-world demonstration of the advantages TLS 1.3 can bring https://nooshu.github.io/blog/2020/07/30/measuring-tls-13-ipv4-ipv6-performance/.

[Carrotman42]

Are you using a connection pool in your app?

Using a connection pool will be objectively more efficient than any other "quick resume" feature of an underlying protocol, since with a connection pool the connection would still be active and therefore we wouldn't need the "quick resume".

[MrMage]

I am not using a connection pool because I am not keen on running another sidecar container in my Pod.

Independent of that, I'd say that adopting the latest measures for security and efficiency sounds like a good idea in general?

[Carrotman42]

Connection pools are usually implemented using a library inside your app, not a separate sidecar, though I suppose these days some people might use a separate container. (Note that a separate sidecar would be less efficient for dialing AND general use than a library, since it's an addition hop for the traffic.) If you don't have access so the source of the application it's harder to do what I'm suggesting, but if you do have the source I would highly recommend that route. If you don't have the source, then consider asking the developers of the application to include some connection pooling. In any case, instead of doing reconnect at the TLS level as suggested in this issue, to me it seems more worthwhile to spend time implementing connection pooling inside the Proxy (tracked at #88). Again, unless I'm mistaken or confusing myself, doing this pooling at the higher level should be more efficient because it should skip even more steps (e.g. it would skip even tcp reconnect). Note that in a similar vein, connection pooling in the application as I previously suggested (which pools connections at the database connection layer) should be more efficient than the Proxy doing it, since it would allow for skipping DB-level authentication. So really, the most efficient thing to do in all situations is to do connection pooling in the app. Just my 2c.

[Carrotman42]

Also, can you clarify how this request is related to security? Seems strictly latency related but I could be missing something.

[MrMage]

Connection pools are usually implemented using a library inside your app, not a separate sidecar, though I suppose these days some people might use a separate container. (Note that a separate sidecar would be less efficient for dialing AND general use than a library, since it's an addition hop for the traffic.) If you don't have access so the source of the application it's harder to do what I'm suggesting, but if you do have the source I would highly recommend that route. If you don't have the source, then consider asking the developers of the application to include some connection pooling. In any case, instead of doing reconnect at the TLS level as suggested in this issue, to me it seems more worthwhile to spend time implementing connection pooling inside the Proxy (tracked at #88). Again, unless I'm mistaken or confusing myself, doing this pooling at the higher level should be more efficient because it should skip even more steps (e.g. it would skip even tcp reconnect). Note that in a similar vein, connection pooling in the application as I previously suggested (which pools connections at the database connection layer) should be more efficient than the Proxy doing it, since it would allow for skipping DB-level authentication. So really, the most efficient thing to do in all situations is to do connection pooling in the app. Just my 2c.

Thank you for the lecture. I know all of this, but the service in question is written in PHP, which makes it very hard to use an in-process connection pool.

And compared to setting up a separate connection pool container or asking this project's maintainers to implement one, I figured that asking for TLS 1.3 support would be a much smaller request while providing a large portion of the benefit for virtually "free". Not to mention additional efficiency and security gains from TLS 1.3.

Also, can you clarify how this request is related to security? Seems strictly latency related but I could be missing something.

The request is primarily about TLS 1.3, which also includes other security and efficiency enhancements. The efficiency argument IMHO is just the most compelling reason to implement it right now.

[Carrotman42]

Sorry for the lecture given you apparently knew all of it. I wasn't aware you knew of the options given your prior comments.

From a bit more research, TLS 1.3 seems to be enabled by default starting in Go 1.14 (which has been released for ~6 months). I don't know for sure what version of Go was used to recompile the latest Proxy release, but if what you're requesting isn't already happening, perhaps all that needs to happen is bumping it to 1.14 and doing a new release.

[kurtisvg]

We've internally already started discussions about supporting TLS 1.3. From our initial investigation, it'll likely only requires changes to the proxy server. There is a bit of work to be done to confirm this, but it is on our radar.

Regarding 0-RTT, it's unclear to me if it's either possible or a good decision to adopt in this case. It may not be possible since the proxy is only ferrying the database protocol, and a resumption at the proxy level may still trigger database auth. Additionally, it seems like one needs to be wary of relay attacks with 0-RTT - I don't know if that is a possibility here, but something we should confirm before pursuing.

I would second @Carrotman42's recommendation for using a connection pool. While I understand it's trickier for PHP since it requires an external process, I do think the benefits significantly out-weigh the inconvenience. Even with TLS 1.3 and 0-RTT it would likely lead to performance improvements from limited the number of connections to your database instance.

[MrMage]

@Carrotman42 Thank you for checking! The current cloud_sql_proxy binary seems to have indeed been compiled with Go 1.13, at least for macOS. Upgrading to Go 1.14 will provide TLS 1.3 support, but apparently [without TLS 1.3 support] (golang/go#9671 (comment)) (possibly due to replay issues).

@kurtisvg Thank you for the elaboration! A quick run of openssl s_client -connect <my CloudSQL IP>:3307 indicated TLS 1.3 support from the proxy server, but I might have misread the output.

Given that the client will automatically get TLS 1.3 support for free when upgrading to Go 1.14 and 0-RTT might not be available/desirable, this can be closed. I will investigate whether a dedicated connection pool will be worth it in my case.