Rust crypto: rustls (+ ring) vs openssl

[tiziano88]

Currently we are using rustls, mostly for convenience in the build process (especially under the musl target).

I think we should be more intentional in the choice of such a fundamental crypto library though. I haven't looked at either option closely, but it feels at some point we should investigate this and decide which one we are comfortable using, and then figure out a way of actually get it to compile.

In addition to the build issues, other issues that came up are whether IP addresses are supported for TLS certificates, though I don't think we should make a decision on the basis of this (unless we end up really being indifferent about the two options otherwise)

ref

• https://github.com/ctz/rustls
  • depends on:
  • https://github.com/briansmith/ring
  • https://github.com/briansmith/webpki
• https://github.com/sfackler/rust-openssl

@daviddrysdale you are probably in the best position to advise on this, so I hope you don't mind me assigning to you to investigate and come to a conclusion (then we can do the actual work of migrating, if any, separately), and giving it a high priority (but feel free to dial it down if you think it does not fit in your planning).

cc @benlaurie FYI

[daviddrysdale]

@conradgrobler, it sounded like you'd found things out about tonic and its (more recent) dependencies – could you summarize?

[daviddrysdale]

Of relevance: http://jbp.io/2020/06/14/rustls-audit.html and https://github.com/ctz/rustls/blob/master/audit/TLS-01-report.pdf

[conradgrobler]

Earlier versions of Tonic supported using either rustls or OpenSSL, but they have recently decided to only support rustls directly (hyperium/tonic#141). It should still be possible to use other options via additional crates (eg https://lib.rs/crates/tonic-openssl) or configuring the TLS at the hyper level rather than using the Tonic convenience wrappers.

[daviddrysdale]

So IIUC:

• The current dep graph is roughly that Oak uses:
  • tonic for gRPC support, which uses:
    • tokio-rustls to make TLS streams accessible in tokio-land, which uses:
      • rustls for TLS support, which uses:
        • webpki for X.509 cert processing, and
        • ring for crypto operations, which uses:
          • BoringSSL for some of its underlying crypto primitives.
• It should be possible to use different dependencies in the middle of that stack, but it would be a bunch of work.
• The stack above seems to be well-respected, and we've only hit one snag with it (lack of support for IP addresses in X.509 certs).

Is that about right?

[conradgrobler]

I think that is about right, yes.

[daviddrysdale]

BTW, the sleevi took a look at X.509 cert chain building recently, and wasn't keen on OpenSSL. The article didn't cover rustls/webpki, but a subsequent tweet had "When using webpki, no issues. When using native TLS, see above".

[tiziano88]

Thanks both for the write up and the links, it was really helpful (to me at least, given my ignorance).

I actually thought that rustls was a pure-Rust implementation from scratch, but it looks like it is actually a mix of Rust and C, and that the C comes actually from boringssl itself. This makes me much more comfortable with it. I am happy to close this issue, @daviddrysdale I'll leave that to you in case you have anything else to mention / check before we do.

[daviddrysdale]

Yep, seems like rustls and its default stack is a sensible choice.