Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is quicpassthrough a good idea? #134

Open
aa51513 opened this issue Sep 5, 2024 · 3 comments
Open

Is quicpassthrough a good idea? #134

aa51513 opened this issue Sep 5, 2024 · 3 comments

Comments

@aa51513
Copy link

aa51513 commented Sep 5, 2024

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
Copy link
Collaborator

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
Copy link

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

@rthellend
Copy link
Collaborator

@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:

  • the proxy doesn't see the plaintext data between the client and the server, and
  • the client and the server can authenticate each other directly with TLS.

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:

  • accept a new QUIC connection
  • after the Client Hello, determine which backend server to use
  • then, forward all the UDP datagrams for that QUIC connection between the client and the backend, in both direction.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants