Using TLS with RustPart III–Will native tls do the trick?
After trying (and failing) to use rustls to handle client authentication, I tried to use rust-openssl bindings. It crapped out on me with a really scary link error. I spent some time trying to figure out what was going on, but given that it said that I wanted to write Rust code, not deal with link errors, I decided to see if the final alternative in the Rust eco system will work, native-tls package.
And… that is a no go as well. Which is sad, because the actual API was quite nice. The reason it isn’t going to work? The native-tls package just has no support for client certificate authentication when running as a server, so not usable for me.
That leaves me with strike three out of three:
- rustls – native Rust API, easy to work with, but doesn’t allow to accept arbitrary client certificates, only ones from known issuers.
- rust-openssl – I have build this on top of OpenSSL before, so I know it works. However, trying to build it on Windows resulted in link errors, so that was out.
- native-tls – doesn’t have support for client certificates, so not usable.
I think that at this point, I have three paths available to me:
- Give up and maybe try doing something else with Rust.
- Fork rustls and add support for accepting arbitrary client certificates. I’m not happy with this because it requires changing not just rustls but also probably webpki package and I’m unsure if the changes I have in mind will not hurt the security of the system.
- Try to fix the OpneSSL link issue.
I think that I’ll go with the third option, but this is really annoying.
More posts in "Using TLS with Rust" series:
- (17 Jan 2019) Authentication
- (11 Jan 2019) Part III–Will native tls do the trick?
- (07 Jan 2019) Part II - Client authentication
- (02 Jan 2019) Part I
To get Rustls to work with your intended scheme, you just need to implement the
ClientCertVerifiertrait and use the "dangerous" configuration option.
client_auth_root_subjectsreturn an empty
verify_client_cert(&self, presented_certs: &[Certificate])hash the first certificate in
presented_certsand check if the hash is in your whitelist.
Use the default implementation of the other two methods.
Brian, Thanks, that's helpful. The provided cert has already been validated at that point (as in, this is a valid cert that the client has a private key of)?