-
Notifications
You must be signed in to change notification settings - Fork 247
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
Consider adding support for other TLS backends #153
Comments
I would like to but I'll not get time. PRs are welcome :) |
Having dug deeper into the fractal of constraints that is rustls + webpki, I have a suggestion. Firstly, reconsider whether rustls is really what you should be using by default! I say this because rustls and webpki are quite web-focused — if you look through their discussions on strictness with certificates, most of it assumes web usage as the context eg. briansmith/webpki#90 (but also several others). This is not a criticism of those projects, but MQTT is not a web protocol, and yet rumqtt seems to be coupled to libraries that are primarily for web infrastructure. But there is a way out that is simpler than a full fledged swappable-backend-API. @mleonhard wrote some example code here: paritytech/x509-signature#4 . It can be used to bypass some of the constraints imposed by webpki and eg. allow self-signed certificates without a SAN. Unfortunately the constraint that certs be v3 still applies, but that might change too: paritytech/x509-signature#2 I have used this example code (to a very limited extent) to get rumqttc to play nice with certificates that are rejected by rustls+webpki out of the box. It might be possible to build some of that into rumqtt so that some of the common IoT configurations (that are otherwise rejected by webpki) work without too much hassle. Unfortunately, I don't have the time to actually do this now 😐 But after spending hours trying to figure out how to advance this, I didn't want to waste my notes. |
@jaredwolff Is it useable from rumqttc's async client? |
Only for server side. |
It would be useful to add ssl as a default feature, so that we can build without SSL support (for example, ring doesn't support certain architectures so, if you have to cross compile, you can't) |
Update: This issue is being worked on in #378 |
Closed since Native-TLS support is now live |
Many crates that require TLS let you choose which backend should be used for it¹. While I would love to eventually switch all our dependencies to rustls, that is not currently possible since we're also using SQLx (cf. launchbadge/sqlx#575). Would you consider supporting openssl and/or native-tls as a backend?
¹ examples: actix-web, attohttpc, rust-s3
The text was updated successfully, but these errors were encountered: