Add support for disabling PQ key exchanges to avoid TLS failures

[olii]

Bug Description

In Readme there is an example how to connect to the AlloyDB instance using SOCKS5 proxy:

ALL_PROXY=socks5://localhost:8000 \
HTTPS_PROXY=socks5://localhost:8000 \
    ./alloydb-auth-proxy <INSTANCE_URI>

The above command works in version 1.11.0 but it fails in the 1.11.1 and 1.11.2.

Looking in the commitlog I think that the update to golang 1.23 broke it.

Example code (or command)

No response

Stacktrace

ALL_PROXY=socks5://<proxy_url>:1080 alloydb-auth-proxy --auto-iam-authn "<instance_string>" --run-connection-test
2024/10/11 17:08:33 Authorizing with Application Default Credentials
2024/10/11 17:08:33 [<redacted>] Listening on 127.0.0.1:5432
2024/10/11 17:08:33 The proxy has started successfully and is ready for new connections!
2024/10/11 17:08:33 Connection test started
2024/10/11 17:08:33 Connection test failed
2024/10/11 17:08:33 The proxy has encountered a terminal error: Dial error: handshake failed (instance URI = "<instance_string>"): EOF

### Steps to reproduce?

1. Run the instance of Alloydb in a private VCP
2. Run a socks5 proxy in kubernets with access to the VCP
3. Run the alloydb-auth-proxy with ALL_PROXY set to the socks5 proxy created in step 2


### Environment

1. OS type and version:  Ubuntu 22.04
2. AlloyDB Proxy version: 1.11.1 +
3. Proxy invocation command (for example, `./alloydb-auth-proxy --port 6000 <INSTANCE_URI>`):


### Additional Details

_No response_

[enocom]

Thanks for the report @olii.

We've seen another unusual problem with the Cloud SQL Proxy when using Go 1.23. See:

• TLS Handshake failures with Go 1.23 cloud-sql-proxy#2296
• TLS handshake failing on Windows with 2.13.0 cloud-sql-proxy#2294.

In short, Go 1.23 introduces a new curve in the default TLS config (golang/go#67061) which we've seen to break VPN connections. Your issue looks the same (handshake fails on EOF).

As a workaround, would you mind reporting if this works for you?

GODEBUG=tlskyber=0 \
ALL_PROXY=socks5://localhost:8000 \
HTTPS_PROXY=socks5://localhost:8000 \
    ./alloydb-auth-proxy <INSTANCE_URI>

Meanwhile, we're working on tracking down whether this is something wrong with Go, something we can do in the Proxy, or a common configuration problem we'll have to deal with. Right now, I don't know what the root issue is.

[olii]

I confirm that I can successfully connect to the SOCKS5 proxy by adding this ENV var GODEBUG=tlskyber=0 to the command line.

Thank you.

[enocom]

Glad to hear it -- we'll be exploring how to remove the need to set GODEBUG meanwhile.

[enocom]

For reference here is a link to the code that sets curve preferences:

https://github.com/golang/go/blob/635c2dce04259f2c84aeac543f0305b3e7c8ed7b/src/crypto/tls/defaults.go#L18-L24

[enocom]

Talking with some folks on the Go team about this, I've learned this is actually a bug in some TLS servers described in http://tldr.fail/.

Basically, some servers incorrectly assume the TLS ClientHello will always be sent in a single TCP packet. With Post-Quantum (PQ) cryptography, that ClientHello is often larger than a single packet. In Go 1.24, there will be explicit curve IDs for the PQ key exchanges, such that we in the Proxy code can easily disable them. Whether we should surface that as a flag, or continue using GODEBUG=tlskyber=0 depends on how soon Go will remove that debug variable.

I'm going to convert this to a feature request in the meantime and leave it open so we can explore options as the ecosystem (and Go) evolves.