See also: #390.

Another advantage of this approach is that a FIPS 140-2 certified implementation could be used where needed. I don’t have such a need, but others do.

What is your issue with ring's approach to backwards compatibility? Have you restricted the number of available ciphersuites so that executable sizes can be reduced at link time?

What is your issue with ring's approach to backwards compatibility?

Updates to ring require time before they can propagate through the ecosystem; during this time, people are running an unsupported version. If ring provided security support to major version N - 1, this would not be anywhere near as much of a problem. Hopefully, ring will reach 1.0 and its API will stabilize.

Have you restricted the number of available ciphersuites so that executable sizes can be reduced at link time?

That isn’t always practical for compatibility reasons, and it still won’t be able to beat linking to a shared system library such as OpenSSL. The vast majority of nasty OpenSSL CVEs have been in the TLS and ASN.1 code, not the cryptography, and I suspect many of the cryptographic ones affect ring too. Using a system crypto library means that I can rely on the OS to handle security updates for it, and that those who need FIPS 140-2 compliance can use rustls at all.

briansmith/ring#535 seems to be planned for the upcoming 0.17 release: briansmith/ring#849 (comment)

Could https://github.com/abetterinternet/crustls become a sufficient system package?
Otherwise it would be great if https://github.com/mesalock-linux/mesalink could become one. An OpenSSL 3.0 API might make it even more attractive for the upcoming transition.

DTLS support is tracked in #40. (DTLS 1.3 IESG state: "In Last Call (ends 2021-02-22)")

As a community we should aim for getting rustls + webpki + ring certified.

As a community we should aim for getting rustls + webpki + ring certified.

FIPS 140-2 certification is very expensive (tens of thousands of USD, IIRC) and very time-consuming (months or years). Only ring would need to be certified, since that’s where the actual crypto is done, but I still believe that trying to get ring FIPS-certified would be a mistake. LibreSSL dropped FIPS support, and Go never supported it at all. There is a branch of Go using the boringcrypto library (based on BoringSSL) that provides an alternative for those users.

In short, the best approach to FIPS 140-2 compliance that I am aware of is to simply offload all cryptography to an OS-provided library. Users who need FIPS 140-2 compliance will then merely need to choose an OS that is already FIPS 140-2 certified, which they would likely need to do anyway.

@DemiMarie Do you yourself need FIPS support? If not, why don't we drop that topic and wait for somebody who actually needs it to ask for it.

BTW, tens of thousands of dollars isn't a lot of money for these projects. Hundreds of thousands of dollars have already been invested into them.

@briansmith I do not. I merely brought it up because I know some people do, and as a reason someone might want to use an alternate crypto backend.

@DemiMarie Do you yourself need FIPS support? If not, why don't we drop that topic and wait for somebody who actually needs it to ask for it.

Red Hat Enterprise Linux needs it. My understanding is that rustls cannot ship in RHEL unless it uses one of RHEL’s existing cryptographic libraries. IIRC, those are libgcrypt, Nettle, NSS, and OpenSSL, along with the kernel cryptographic code.

Ran into so many problem with building ring (cross-compiling, linking, etc). This is one of the reason why we dropped rustls in favor of openssl. Seems like crypto should be treated like OS service.

Ran into so many problem with building ring (cross-compiling, linking, etc). This is one of the reason why we dropped rustls in favor of openssl. Seems like crypto should be treated like OS service.

It is in fact treated as such, on all major platforms.

@ctz: would you accept a high-quality PR that included an OpenSSL backend?

People who need that might be better served by using rust-native-tls.

People who need that might be better served by using rust-native-tls.

I consider rustls to be a better TLS implementation than OpenSSL. The majority of OpenSSL’s security holes have not been in the crypto, but rather memory safety issues elsewhere. Since most of the problems with rustls seem to be due to ring, using OpenSSL for the crypto instead seems to be an obvious alternative.

I have also encountered a lot of issues regarding ring, cross-compiling, linking and the multi version issue of ring ( the most annoying one for me personally ).

Given the above, I still do not believe that changing rustls to include openssl as a backend is the right approach, since it might actually hinder development for this project.

I think the correct approach would be to create a wrapper-crate towards the entire rustls, and unyfing on an API, that could in turn switch between rust-native-tls and rustls, preferably in a drop-in manner, meaning that if one were to write an application or library using rustls, but needing a feature that is currently not in rustls because of some dependency. Then that would be treated as a "quick and dirty fix" until such time as it is supported by rustls.

The "quick and dirty fix" and "until", is the basis for my reasoning, since I believe that creating a drop-in wrapper crate would be faster. And that it should be a treated as a temporary ( yeah, i know) solution to using rustls.

The multi-version issue in ring is mostly fixed in ring's main branch now; see briansmith/ring#1268. Review and testing of that by others would be appreciated.

Cross-compilation of ring has made big progress in ring's main branch as well. IIRC, there is now a C or Rust fallback for everything, so platforms for which ring doesn't have assembly language code are now supported. There is work underway to verify this with the MIPS little-endian port. After that, I think we'll have to clean up some stuff that's not supported for big-endian archs yet, but that should be relatively easy.

The multi-version issue in ring is mostly fixed in ring's main branch now; see briansmith/ring#1268. Review and testing of that by others would be appreciated.

Cross-compilation of ring has made big progress in ring's main branch as well. IIRC, there is now a C or Rust fallback for everything, so platforms for which ring doesn't have assembly language code are now supported. There is work underway to verify this with the MIPS little-endian port. After that, I think we'll have to clean up some stuff that's not supported for big-endian archs yet, but that should be relatively easy.

Personally, I wold still like to be able to link to system-provided cryptographic libraries instead. The main reasons (in no particular order) are:

1. It is a hard requirement for packaging in some distributions, such as RHEL and its derivatives.
2. Having to statically link ring increases the size of the executable.
3. System-provided cryptographic libraries receive security updates without me having to take any action at all, whereas programs using ring need to be recompiled if there is a security issue in ring.

In short, I am not particularly interested in rust-native-tls, as I consider rustls to be better than native platform implementations. I am much less convinced when it comes to ring, and there are significant advantages to using system libraries for actual cryptographic primitives. On Linux and *BSD, these problems could be mitigated if ring were a system library I could dynamically link to.

I now think it would be valuable to add high-level traits in rustls that abstract over the crypto operations. If we were to do that, I don't think we should include other implementations as part of rustls -- it would be up to downstream users to decide whether to trust another implementation. We might even guard the use of alternative implementations with a feature flag like dangerous_configuration. I also think that we should likely still restrict alternative implementations to the cipher suites/signature schemes/key exchange groups currently supported in this crate, at least as a first iteration.

I'd second that. One of the recommendations in the audit was to use formally verified crypto. High-level crypto traits would allow rustls to do so, for example using evercrypt.

@briansmith So, I like Rust (a lot) and I have a lot of folks that need FIPS compliance.

As mentioned, RHEL implemented go-toolchain to allow golang apps to automatically hook into the underlying FIPS-approved crypto.

This would be a HUGE boon to the adoption of Rust in places that require FIPS crypto.

This is also a hard requirement to use hardware cryptographic accelerators. These require cryptography to be asynchronous, as they have very deep pipelines that need to be kept full.

Is there any further discussion? Our community hopes to be able to provide a backend for wasi-crypto, and a middle layer is essential. I wish to get some tips about how to design it and pull request back to the upstream. WasmEdge/WasmEdge#1430

There has not been any further discussion. If you or your community wants to work on this, I'd be open to reviewing a potential design. I think essentially it would have to be a high-level set of traits that essentially mimic the current ring API to cover the rustls crypto requirements that are not currently covered by traits.

Maybe the tls-api crate could used, if not directly, then as a starting point for trait/API design: https://docs.rs/tls-api/0.9.0/tls_api/

That is a very different level of abstraction, which wouldn't allow re-use of the non-cryptography code in rustls.

This is great. Another use case for alternate backends: rustls-ffi uses Miri for testing, but has to disable Miri on most of the interesting code paths because they call out to FFI (assembly) code in ring, and Miri does not support calling out to FFI. If we have a backend with no FFI, rustls-ffi should be able to make more extensive use of Miri to verify correctness of its unsafe code.

Above it was said that ring has fallback paths in Rust -- do those not get used with Miri for some reason or are there no fallback paths for some operations?

(Also obligatory reminder that Miri by default provides deterministic execution, so don't run any code that needs proper randomness in Miri on real data!)

Honestly I had missed that there were fallbacks. Though note:

there is now a C or Rust fallback for everything

A C fallback isn't much use for Miri because it's still FFI, right?

@djc any updates on this?

A C fallback isn't much use for Miri because it's still FFI, right?

True.

For the current state, have a look at #1405. In short, the next semver-incompatible rustls release (which we expect to happen within a few weeks from now) will have support for pluggable crypto providers.

Amazing, I totally missed that! looking forward to trying it out

This is awesome progress. I have a (possibly naive) question.

How do we audit what provider the compiled application is configured to use?

As in, given binary X, what do I run to determine if it is using a provider that is allowed by my organization?

AFAIK https://github.com/rust-secure-code/cargo-auditable could help you tell which dependencies are compiled into your binary. That should be an important part of the puzzle, although in any given binary there might be multiple sites that instantiate a rustls config and all of these might use a different crypto provider, and that might be harder to check from a binary.

AFAIK https://github.com/rust-secure-code/cargo-auditable could help you tell which dependencies are compiled into your binary. That should be an important part of the puzzle, although in any given binary there might be multiple sites that instantiate a rustls config and all of these might use a different crypto provider, and that might be harder to check from a binary.

@djc That's what I suspected. It's definitely a use case that should be accounted for at some point but it sounds like the "right answer" is to always compile from scratch at this point. ( cries in 90's pre-packaging hell )

AFAIK https://github.com/rust-secure-code/cargo-auditable could help you tell which dependencies are compiled into your binary. That should be an important part of the puzzle, although in any given binary there might be multiple sites that instantiate a rustls config and all of these might use a different crypto provider, and that might be harder to check from a binary.

@djc That's what I suspected. It's definitely a use case that should be accounted for at some point but it sounds like the "right answer" is to always compile from scratch at this point. ( cries in 90's pre-packaging hell )

If you need to only use FIPS 140-certified cryptography, then you will likely need to build everything yourself indeed. There are lots of other Rust cryptographic libraries out there and you will need to make sure that none of them are built, or replace them with versions that call whatever certified cryptography is on your system.

@DemiMarie It is certainly making rust a minefield for certified crypto and I agree on essentially needing to do a full code audit and build.

Unfortunately, the burden is almost to the point of untenable for large application bases.

Could you detail what your requirements are? Is it just the normal FIPS140 ones, ie all cryptography must be FIPS approved or FIPS allowed, and approved cryptography must be a FIPS140-certified implementation? Anything more than this?

@ctz That's the one. But that only applies for everything that uses cryptography for the "protection of sensitive data". This means hash algorithms down the stack and, of course, the correct configuration of each.

It gets more complicated by the fact that technically you can use non-FIPS algorithms as long as you're not using them for "protection of sensitive data". It's easier to just ban them outright but not actually required.

So, could I use the md-5 crate for doing a bunch of checksums to prevent collisions on temp files in the filesystem that can't affect a security path? Sure! Is it hard to determine that I'm using it specifically for that use...yes.

Some languages have the ability to toggle FIPS with a setting that essentially says "I'm doing the bad thing but it's OK". Likewise, some vendor implementations tie them into lower levels that remove the algorithms altogether for safety and break that application path.

But, in the end, the questions that needs to be answered are:

• US and Canada
  • Am I using algorithms that meet the FIPS requirements.
• Other folks that care
  • ISO/IEC 19790 and ISO/IEC 24759 which are the foundation for FIPS 140-3 (but not sufficient).

@trevor-vaughan Do you just need to use approved algorithms, or do you need certified implementations of those algorithms? The latter is likely going to mean sending a bunch of patches upstream — there are good reasons (notably better APIs) why people use pure-Rust crypto implementations over the system libraries.

@DemiMarie If you need to meet the FIPS requirement, it must be the certified implementation.

Per the official CMVP page:

Non-validated cryptography is viewed by NIST as providing no protection to the information or data—in effect the data would be considered unprotected plaintext. If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2 or FIPS 140-3 is applicable. In essence, if cryptography is required, then it must be validated. Should the cryptographic module be revoked, use of that module is no longer permitted.

@trevor-vaughan we'd definitely like to make rustls an option for FIPS-certified environments so would be interesting to hear more about what challenges you have with Rust compared to, say, C++. Might also be interesting to bring this up in the wg-secure-code stream in the rustlang Zulip.

@djc Right now, it's more rust vs golang. Golang == recompile the thing one of two ways and you're gold (as long as someone didn't do something silly).

In the case of any compiled language, you're definitely at the mercy of the one doing the compiling and I'm definitely starting to have 1990's zlib flashbacks :-(.

The problem we have for OpenSUSE is much simpler - we have to build some projects on arches that arent x86_64/aarch64. Ring almost constantly fails to build on these. Because rustls is used so commonly, with no alternatives in projects, then it means we can't build a lot of projects that depend on rustls for other arches.

So having the ability to set alternate cryptographic backends would help us here by allowing us to build more easily on alternate arches.

@trevor-vaughan sorry, it's not very clear to me what you mean here with the Go vs Rust compilation issue. I think you're suggesting that Rust's compilation model causes issues for your FIPS story, but I don't understand why?

@djc I came upon this issue when I was trying to find "the way" to flip the Rust backend over to use openssl natively.

Golang provides crypto as it's "standard" crypto library and has two methods for swapping it into a FIPS-supported mode. One is to use boringcrypto (and follow the actual FIPS documentation) and the other is provided by Red Hat that essentially shims the underlying openssl stack into the crypto hooks and, therefore, inherits the certification from the underlying platform.

IIRC, in the early days, Rust pretty much used openssl straight and then decided to essentially modularize the whole crypto set. This made it pretty much impossible to flip any given compile into a FIPS compliant mode since you had to play whack-a-mole with every package out there.

In both cases (and every other language) you do have to make sure that someone isn't dragging in some random package to do crypto but the golang (and javascript, python, etc...) pattern of having a "core" crypto library that 99% of folks use makes it much easier for regulatory focused shops.

Ah, so you're talking about the dependency graph model that Cargo has.

So from this perspective, would it help you if the rustls ring backend lived in a separate crate, so that you could check your Cargo.lock file to make sure that it's not getting compiled in?

So from this perspective, would it help you if the rustls ring backend lived in a separate crate, so that you could check your Cargo.lock file to make sure that it's not getting compiled in?

🤔 Actually, yes, that might help quite a bit. Any way that makes it easier to determine exactly what is in use (or not) is a win.

We've made a start on this in the recent 0.22 release. Shipping FIPS140 support is tracked in #1540.