Usability with TLS trust anchors #101
Comments
|
This is a really good question! So most gRPC examples I've seen have their own ca roots so I have not really seen users require this but I think its something we might be able to support. I'm not opposed to adding an additional feature flag around adding default roots. So I believe the @jen20 any thoughts? |
LucioFranco
added
A-tonic
C-enhancement
|
I think we should definitely expose a way to make this simpler - I'll take a look into some of the options and have a think about what could be done. |
|
I spent some time this week to learn a bit about TLS and certificate trust chains. I found the docs at Let's Encrypt to be super useful! It's now a little more clear now that I am guessing GRPC community feels pretty comfortable with these certs because they keep updated the Mozilla root certificates in their git repo. I asked around in the GRPC gitter and I think they simply bake in the certs to the GRPC libraries. This is useful when running on an OS like windows where there is no standard location for trusted certs. I think it may be useful to either:
Either option would address the basic needs for users like me, and any users who care about initialization cost or root certs wouldn't need to pay the cost by default. |
|
Hi @xmclark! Personally I think I'd tend towards option 1 here. I can likely put together a pull request for this fairly quickly, as I have some other work in flight for TLS bits. |
|
Option one sounds like a great idea! |
As per hyperium#101, it is sometimes desirable to use standard web PKI roots for gRPC clients. This commit adds a method to ClientTlsConfig to allow this. The behaviour differs per TLS library: - OpenSSL uses `openssl-probe` to search the system for roots and add them. - Rustls adds the Mozilla-supplied roots from the `webpki-roots` crate. This is not feature flagged, as there appears to be no convenient way to gate a dependency on multiple conditions.
As per hyperium#101, it is sometimes desirable to use standard web PKI roots for gRPC clients. This commit adds a method to ClientTlsConfig to allow this. The behaviour differs per TLS library: - OpenSSL uses `openssl-probe` to search the system for roots and add them. - Rustls adds the Mozilla-supplied roots from the `webpki-roots` crate. This is not feature flagged, as there appears to be no convenient way to gate a dependency on multiple conditions.
As per hyperium#101, it is sometimes desirable to use standard web PKI roots for gRPC clients. This commit adds a method to ClientTlsConfig to allow this. The behaviour differs per TLS library: - OpenSSL uses `openssl-probe` to search the system for roots and add them. - Rustls adds the Mozilla-supplied roots from the `webpki-roots` crate. This is not feature flagged, as there appears to be no convenient way to gate a dependency on multiple conditions.
As per hyperium#101, it is sometimes desirable to use standard web PKI roots for gRPC clients. This commit adds a method to ClientTlsConfig to allow this. The behaviour differs per TLS library: - OpenSSL uses `openssl-probe` to search the system for roots and add them. - Rustls adds the Mozilla-supplied roots from the `webpki-roots` crate. This is not feature flagged, as there appears to be no convenient way to gate a dependency on multiple conditions.
|
Super happy to see #114 opened. I pointed my current grpc project using tonic to the I don't mind tonic paying the extra cost of importing the mozilla certs for rustls usage. I think most other grpc libraries do this by default anyways. |
As per hyperium#101, it is sometimes desirable to use standard web PKI roots for gRPC clients. This commit adds a method to ClientTlsConfig to allow this. The behaviour differs per TLS library: - OpenSSL uses `openssl-probe` to search the system for roots and add them. - Rustls adds the Mozilla-supplied roots from the `webpki-roots` crate. This is not feature flagged, as there appears to be no convenient way to gate a dependency on multiple conditions.
As per hyperium#101, it is sometimes desirable to use standard web PKI roots for gRPC clients. This commit adds a method to ClientTlsConfig to allow this. The behaviour differs per TLS library: - OpenSSL uses `openssl-probe` to search the system for roots and add them. - Rustls adds the Mozilla-supplied roots from the `webpki-roots` crate. This is not feature flagged, as there appears to be no convenient way to gate a dependency on multiple conditions.
As per hyperium#101, it is sometimes desirable to use standard web PKI roots for gRPC clients. This commit adds a method to ClientTlsConfig to allow this. The behaviour differs per TLS library: - OpenSSL uses `openssl-probe` to search the system for roots and add them. - Rustls adds the Mozilla-supplied roots from the `webpki-roots` crate. This is not feature flagged, as there appears to be no convenient way to gate a dependency on multiple conditions.
|
I just saw announcement for rustls-native-certs. This may be something else to consider. It has cross platform support. |
|
Oh very nice! @jen20 happy with what ever you think we should go with |
|
I'll update #114 to use the native certs crates, that is likely a more appropriate option than simply relying on the Mozilla roots. |
As per hyperium#101, it is sometimes desirable to use standard web PKI roots for gRPC clients. This commit adds a method to ClientTlsConfig to add the trust roots from the system certificate store: - OpenSSL uses `openssl-probe` to search the system for roots. - Rustls uses `rustls-native-certs` to load the system roots. Enabling the `openssl-roots` or `rustls-roots` feature for `tonic` in `Cargo.toml` will add system roots by default when configuring a gRPC client.
As per hyperium#101, it is sometimes desirable to use standard web PKI roots for gRPC clients. This commit adds a method to ClientTlsConfig to add the trust roots from the system certificate store: - OpenSSL uses `openssl-probe` to search the system for roots. - Rustls uses `rustls-native-certs` to load the system roots. Enabling the `openssl-roots` or `rustls-roots` feature for `tonic` in `Cargo.toml` will add system roots by default when configuring a gRPC client.
As per hyperium#101, it is sometimes desirable to use standard web PKI roots for gRPC clients. This commit adds a method to ClientTlsConfig to add the trust roots from the system certificate store: - OpenSSL uses `openssl-probe` to search the system for roots. - Rustls uses `rustls-native-certs` to load the system roots. Enabling the `openssl-roots` or `rustls-roots` feature for `tonic` in `Cargo.toml` will add system roots by default when configuring a gRPC client.
As per #101, it is sometimes desirable to use standard web PKI roots for gRPC clients. This commit adds a method to ClientTlsConfig to add the trust roots from the system certificate store: - OpenSSL uses `openssl-probe` to search the system for roots. - Rustls uses `rustls-native-certs` to load the system roots. Enabling the `openssl-roots` or `rustls-roots` feature for `tonic` in `Cargo.toml` will add system roots by default when configuring a gRPC client.
As per hyperium#101, it is sometimes desirable to use standard web PKI roots for gRPC clients. This commit adds a method to ClientTlsConfig to add the trust roots from the system certificate store: - OpenSSL uses `openssl-probe` to search the system for roots. - Rustls uses `rustls-native-certs` to load the system roots. Enabling the `openssl-roots` or `rustls-roots` feature for `tonic` in `Cargo.toml` will add system roots by default when configuring a gRPC client.
Bug Report
This bug reports some usability issues with TLS in
tonic.Version
tonic = "0.1.0-alpha.3"
tonic-build = "0.1.0-alpha.3"
Platform
Windows 64-bit
Description
When building a grpc client with
tonicandrustlsflag, without specifying a certificate in the builder, I expectedtonicto find my server's certificate in the root store, but instead I get some pretty cryptic error messages out ofwebpkicrate.I did some digging, and even opened an issue on
webpki. The short of it: Tonic is able to build a full certificate chain. That's about all I know about that topic! I really know nothing about it. What fixed it for me was adding a line like this when creating my client config:tls.root_store.add_server_trust_anchors(&webpki_roots::TLS_SERVER_ROOTS);I don't know exactly what this line does, but it does fix my problem. It does require a new dependency on the
webpki_rootscrate.I could set the trust anchors manually, but it would circumvent a lot of the boilerplate tonic provides around
rustlsandClientConfig.Does it make sense to add this behavior and dependency to
tonic? My first reaction is no, but this seems like something others might trip on, and it would be nice iftonicexposed this for free for users like me that need it. Perhaps behind a feature flag? I also don't know if OpenSSL operates the same way and would take advantage of the feature in the same way. I wasn't able to try it because OpenSSL linking is a bit awkward on windows.I'm happy to PR a change in!
The text was updated successfully, but these errors were encountered: