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

Consider adding support for other TLS backends #153

Closed
jplatte opened this issue Sep 29, 2020 · 8 comments
Closed

Consider adding support for other TLS backends #153

jplatte opened this issue Sep 29, 2020 · 8 comments
Labels
feature request Discussion around feature addition good first issue Good for newcomers in-pipeline Planned to be resolved in a future release

Comments

@jplatte
Copy link
Contributor

jplatte commented Sep 29, 2020

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

@tekjar
Copy link
Contributor

tekjar commented Sep 30, 2020

I would like to but I'll not get time. PRs are welcome :)

@detly
Copy link
Contributor

detly commented Nov 24, 2020

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

@jplatte @detly FYI native-tls has been implemented.

@jplatte jplatte closed this as completed May 25, 2021
@detly
Copy link
Contributor

detly commented May 27, 2021

@jaredwolff Is it useable from rumqttc's async client?

@jaredwolff
Copy link
Contributor

Only for server side.

@jplatte jplatte reopened this May 27, 2021
@eutampieri
Copy link

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)

@de-sh de-sh added feature request Discussion around feature addition good first issue Good for newcomers in-pipeline Planned to be resolved in a future release labels Mar 6, 2022
@123vivekr
Copy link
Contributor

123vivekr commented Mar 20, 2022

Update: This issue is being worked on in #378

@de-sh
Copy link
Member

de-sh commented Dec 15, 2022

Closed since Native-TLS support is now live

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Discussion around feature addition good first issue Good for newcomers in-pipeline Planned to be resolved in a future release
Projects
None yet
Development

No branches or pull requests

7 participants