rustls VS ring

The RustTLS project is currently setting up their own CI benchmarking workflow, so I think that you could find some inspiration there: https://github.com/rustls/rustls/issues/1385 and https://github.com/rustls/rustls/issues/1205.

I also studied this question on FFI several weeks ago in terms of "rewrite part of the system in Rust". Unexpected results could be semantic issues (e.g., different error handling methods) or security issues (FFI could be a soundness hole). I suggest going through the issues of libraries that have started rewriting work such as rust-openssl or rustls (This is the one trying to rewrite in whole rust rather than using FFI; however, you will not be able to find the mapping function in the C version and compare them). I hope this helps!

Now for rust implementation of tls. Certificates can be loaded in two ways. * Finds and loads certificates using OS specific tools3 * Uses a rust implementation of webpki4 for loading with certificates5

> Ring is mostly C/Assembly

Crypto needs to be written in Assembly to ensure that operations take a constant time, regardless of input. Writing it in a high level language like C or Rust opens you up to the compiler "optimising" routines and making them no longer constant time.

But you already knew this. And you also knew that the security audit (https://github.com/rustls/rustls/blob/master/audit/TLS-01-re...) of ring was favourable

> No issues were found with regards to the cryptographic engineering of rustls or its underlying ring library. A recommendation is provided in TLS-01-001 to optionally supplement the already solid cryptographic library with another cryptographic provider (EverCrypt) with an added benefit of formally verified cryptographic primitives. Overall, it is very clear that the developers of rustls have an extensive knowledge on how to correctly implement the TLS stack whilst avoiding the common pitfalls that surround the TLS ecosystem. This knowledge has translated reliably into an implementation of exceptional quality.

You said

> a standard library with feature flags and editions would make rust ridiculously much more productive

What's the difference between opting into a library with a feature flag and opting in with a line in Cargo.toml? Let's say you want to use the de-facto regex library. Would it really be ridiculously productive if you said you wanted the "regex" feature flag instead of the "regex" crate?

I do agree that the standard library does need a versioning story so they can remove long deprecated functions. Where it gets complicated is if a new method is reintroduced using the same name in a later edition.

I used the commands listed in the .sh file here: https://github.com/rustls/rustls/tree/main/test-ca to generate keys/certs for a server and a client (with IP.1 records for SANs). I have added the local root CA to the trust store of each VM.

This is great news, this was our single biggest annoyance with rustls. One of our cloud providers choses to issue their hosted postgres instances with TLS certificates with IP addresses. Unusual, but valid per the spec, so why not. Apparently a practise that's also popular in kubernetes settings, so I'm somewhat surprised it took 5 years to close the issue, but now I can finally recommend people to use rustls without mentioning any gotchas.

I believe it is more relevant than you think: servers running in containers, web assembler tasks running in browsers, embedded devices and kernels with total control of the system, all have the ability to do something more sensible than plain out SIGABRT or similar, and in many the case is not that the complete system is falling down. For example RustTLS is looking into allowing fallible allocators and as a pretty general-purpose library that seems like a nice feature. I do wish ulimit -v worked in a sensible manner with applications.

Again, this is just a temporary situation, and a matter of burning down a list of small tasks. Not that the OpenSSL license issue is a big deal for most anyway. Feel free to help; see this issue filed by Josh Triplett: https://github.com/briansmith/ring/issues/1318#issuecomment-...

Note also that rustls depends on ring, which has architecture-dependent code in it that is not as widely compatible as eg. OpenSSL/GnuTLS/Mbed-TLS. For example, MIPS is not supported by ring.

The AWS Rust library we were using as a dependency depended on a cryptography library called ring. This library leverages C and assembly code to implement its cryptographic primitives. Unfortunately, cross compiling when C is involved can add complexity to the build process. While it might've been possible to overcome these issues I decided that it wasn't worth digging into more.

That'd be great. Thanks Brian. Re: making ring portable to all platforms: IBM have been graciously maintaining a up to date patchset for Ring for years now and there's an outstanding PR here you may not have seen since they filed it in 2020... https://github.com/briansmith/ring/pull/1057

Beyond the simple matter of Rust being much newer than OpenSSL, one concern for some cryptographic primitives is the timing side-channel.

https://en.wikipedia.org/wiki/Timing_attack

In high level languages like Rust, the compiler does not prioritise trying to emit machine code which executes in constant time for all inputs. OpenSSL has implementations for some primitives which are known to be constant time, which can be important.

One option if you're working with Rust anyway would be use something like Ring:

https://github.com/briansmith/ring

Ring's primitives are just taken from BoringSSL which is Google's fork of OpenSSL, they're a mix of C and assembly language, it's possible (though fraught) to write some constant time algorithms in C if you know which compiler will be used, and of course it's possible (if you read the performance manuals carefully) to write constant time assembly in many cases.

In the C / assembly language code of course you do not have any safety benefits.

It can certainly make sense to do this very tricky primitive stuff in dangerous C or assembly, but then write all the higher level stuff in Rust, and that's the sort of thing Ring is intended for. BoringSSL for example includes code to do X.509 parsing and signature validation in C, but those things aren't sensitive, a timing attack on my X.509 parsing tells you nothing of value, and it's complicated to do correctly so Rust could make sense.

machine learning, neural networks, image processing, cryptography (though it is getting better), font shaping/rendering (though it is getting better), CPU/software rendering (though it is getting better)