Support for alternative TLS backends

[dignifiedquire]

I am currently looking at alternatives for quinn, but due to my current usage, I am relying on rustls for TLS handling (platform support, and custom certificate verification). So I was wondering if you are open to enabling different TLS backends. Either in a fully generic form, or by feature flagging boringssl & rustls.

[glime-ai[bot]]

TQUIC, as detailed in the documentation, primarily supports TLS configurations through its Rust API. It allows for the export of TLS keys in the NSS key log format, which is compatible with tools like Wireshark for packet decryption and analysis. This indicates a flexible approach to TLS handling within the TQUIC framework.

However, the documentation does not explicitly mention support for rustls or the ability to switch TLS backends via feature flags or a fully generic form. The current implementation seems to be tied to its own TLS configuration methods, which might not directly support rustls without modifications to the library.

If you are considering TQUIC as an alternative to quinn and require specific TLS backend support like rustls, it would be advisable to reach out directly to the TQUIC development team. You can contribute to the project or request this feature by creating an issue on their GitHub repository or participating in their community discussions.

For more detailed information or to request this feature, you can visit the following links:

• TQUIC GitHub Repository: TQUIC GitHub
• TQUIC Community Discussions: TQUIC Discussions

This comment was generated by Glime.

[dignifiedquire]

Adding support for rustls, would likely make supporting windows #44 easier as well.

[iyangsj]

Our current design encapsulates the dependency on the TLS library. We did this on purpose so we can easily switch to or add other TLS libraries later on. We're thinking about adding rustls to later versions to take advantage of Rust's memory safety.