-
Notifications
You must be signed in to change notification settings - Fork 1k
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
feat(transport): Expose more granular control of TLS configuration #48
feat(transport): Expose more granular control of TLS configuration #48
Conversation
43f60fa
to
f624e8d
Compare
After playing with this some more, and the suggestions in #47 I've reworked this to use a new builder for TLS options. This allows us to expose several different levels of abstraction for configuring TLS while not creating sprawl in the |
cb010c9
to
87d6549
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks fantastic! Really happy with how it turned out. I left some comments inline.
tonic/src/transport/endpoint.rs
Outdated
} | ||
|
||
/// Sets the CA Certificate against which to verify the server's TLS certificate. | ||
pub fn ca_certificate(mut self, ca_certificate: Certificate) -> Self { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about this taking &mut self
and returning &mut Self
like the other builders?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've had a look at this, but we have the issue that we want to take the SslConnector
and ClientConfig
values from the builder? Happy to look at alternatives though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe the configs should be cheaply clonable right? So that means we can take a &self and get a full version.
6e520f5
to
7f0dfca
Compare
Thanks for the feedback @LucioFranco - most of the issues you raised are now addressed, with a couple of additional questions inline. |
This commit reworks TLS configuration of both servers and endpoints in order to provide a more flexible API. We now add options to configure the selected TLS library using the appropriate 'native' configuration structures, as well as retaining the existing simplier interface which is compatible with both. The new API can also be easily extended to support simple interfaces for configuring mTLS and a range of other options without creating sprawl in the builders for `Server` and `Endpoint`.
7f0dfca
to
95bc8ee
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you so much for this! Super happy to land this!
Thanks! Next up I’m going to look at mutual TLS, I’ll likely have a write up of the options some time tomorrow morning (EU time). |
…yperium#48) This commit reworks TLS configuration of both servers and endpoints in order to provide a more flexible API. We now add options to configure the selected TLS library using the appropriate 'native' configuration structures, as well as retaining the existing simplier interface which is compatible with both. The new API can also be easily extended to support simple interfaces for configuring mTLS and a range of other options without creating sprawl in the builders for `Server` and `Endpoint`.
This is the start of an implementation of the solution for exposing more granular control over TLS as described in #47.
It is currently incomplete, but does not lose any functionality over the previous API and should help inform whether this is the path we want to go down or not.