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

Introduce TlsConnect and QuicConnect trait to be more flexible #2137

Open
zh-jq-b opened this issue Feb 6, 2024 · 4 comments
Open

Introduce TlsConnect and QuicConnect trait to be more flexible #2137

zh-jq-b opened this issue Feb 6, 2024 · 4 comments

Comments

@zh-jq-b
Copy link
Contributor

zh-jq-b commented Feb 6, 2024

Is your feature request related to a problem? Please describe.

The tls connect code should be same for DoT and DoH, for DoT we have rustls / openssl / native-tls support, but for DoH we only have rustls support, this should be changed to allow more flexible selection of tls libraries and the version.

And the tls connect code is simple, has little to do with the dns code, so they should be split out to avoid unnecessary major version bumps when the tls crate released new major versions.

Describe the solution you'd like

We should add TlsConnect trait, which will convert a TcpStream into a TlsStream<TcpStream>, and use separate crate such as hickory-rustls, hickory-openssl, hickory-native-tls to provide impls, and it wouldn't be too much work to add new impls for users when they want to use a new tls crate or when they need to update rustls to a new version.

We should add QuicConnect trait, to create h3 SendRequest<_> and also poll the close of the connection. The use of h3_quinn crate can be split into a hickory-quinn crate, and users can use their own h3 quic backend crates as long as the use the same h3 major version.

@djc
Copy link
Collaborator

djc commented Feb 6, 2024

What is the actual problem you're trying to solve?

@zh-jq-b
Copy link
Contributor Author

zh-jq-b commented Feb 7, 2024

What is the actual problem you're trying to solve?

First, to use other tls / quic backends such as boringssl or quiche.
Second, to be able to update the tls / quic backends independently.

@djc
Copy link
Collaborator

djc commented Feb 7, 2024

Out of curiosity, can you give more context on why you/Bytedance want to use different TLS/QUIC backends?

@zh-jq-b
Copy link
Contributor Author

zh-jq-b commented Feb 8, 2024

I have forked a variant-ssl crate from openssl, which added support Tongsuo and AWS-LC that won't be accepted by openssl crate. So I don't want to have another openssl dependency.

We have been using rustls in the G3 project for all of the hickory features,
but for this part, it's really a long time to wait when we want to update the version to 0.22 (rustls -> quinn -> h3_quinn -> hickory), I can disable the DoQ and DoH3 features for some time, but I don't want to disable DoT and DoH features.

And we may also have to support TLCP (a TLS variant protocol that is officially promoted in China) usage in DoT and DoH, so we have to use Tongsuo or some other tls crates in such case.

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

2 participants