c2FmZQ / tlsproxy

A TLS proxy, Reverse proxy, and Web server that uses Let's Encrypt automatically.
MIT License
47 stars 4 forks source link

Is quicpassthrough a good idea? #134

Open aa51513 opened 2 months ago

aa51513 commented 2 months ago

quicpassthrough is similar to tlspassthrough, listening for quic connections on the same port and sending to different backends based on the quic sni(or server_name)

Do you think this is a good idea?

I have checked a lot of documents and information, but couldn't find any software or product with this function.

rthellend commented 2 months ago

I agree this would be a nice feature. I don't know how feasible it is.

It would require parsing all the udp datagrams, keeping track of all the quic connections without decrypting the data, and then forwarding the raw datagrams somewhere else. I don't know if this is even possible to do that with QUIC. If it is possible, we'd need to re-implement (or re-use) logic from quic-go to make it work. @marten-seemann would know better.

marten-seemann commented 2 months ago

Not sure what exactly you're trying to achieve, but are you familiar with RFC 9298 and RFC 9484?

rthellend commented 2 months ago

@marten-seemann

TLS passthrough is a popular feature of network proxies / load balancers where a proxy terminates the TCP connection, but not the TLS connection. The proxy inspects the Client Hello message, which is not encrypted, and uses information contained in that message to make routing decisions. Most commonly, the SNI is used to decide where the TCP stream should be forwarded.

The main reasons for doing this are:

With regular TLS over TCP, this is pretty straight forward to implement. We just need to know how to parse the Client Hello message, and bridge two TCP connections.

Now, the question here is whether the same thing can be done with QUIC. The proxy / load balancer would need to:

My understanding is that QUIC and TLS are very tightly coupled. I don't know if it is even possible to do this.