FIPS Support

[markmsmith]

Feature

I'd like to be able to run a build of Wasmtime that has wasi-http configured to run in FIPS mode. This would mean that all https requests and responses would use a NIST-certified crypto module.
This could just be a separate build of Wasmtime and wouldn't need to be dynamic per-request or per-VM.

Benefit

If I want to run Wasmtime in a US Gov "FedRAMP Moderate" or higher environment, I need to be able to show auditors that any encryption-in-transit is done with a crypto module that's been NIST-certified as FIPS-140-2 or FIPS-140-3 compliant. As an example, the Golang 1.24+ crypto module 1.0.0 was just validated last week, so any golang programs built with the appropriate flags are guaranteed to use the appropriate crypto implementation. Ideally Wasmtime could support something similar for its WASI implementations.

Implementation

It looks like wasi-http depends on rustls:
https://github.com/bytecodealliance/wasmtime/blob/main/crates/wasi-http/Cargo.toml#L43

I'm not a rust expert, but I believe Rustls can support support FIPS via the aws-lc-rs backend

• Optionally support a FIPS-approved CryptoProvider rustls/rustls#1540 (comment)
• https://docs.rs/rustls/latest/rustls/crypto/fn.default_fips_provider.html

This could potentially allow either a FIPS build of Wasmtime, or for FIPS a mode to be surfaced via config.

Here's are the NIST certificates for the various versions of the aws-lc crypto module:
https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search?SearchMode=Basic&ModuleName=aws-lc&CertificateStatus=Active&ValidationYear=0

Alternatives

1. Have wasi-http delegate to wasi-crypto and have wasi-crypto be the one that supports FIPS at a lower-level. This would be a more generic solution, making FIPS also available to applications that are using wasi-crypto instead of just consumers of wasi-http, but that also increases the API surface area and scope of this request. My use case only require https requests and responses go through a NIST-certified crypto module, so a narrower scoped solution seemed the best incremental approach. If successful, wasi-crypto could still be considered in a future iteration, but might use aws-lc-rs directly instead of going through rustls.
2. Allow some other way to plugin in a FIPS-140-3 compliant crypto module. If this doesn't ship as part of Wasmtime, it would make the setup of the containerd shim in SpinKube more complicated.
3. Implement a pure-wasm implementation of the crypto and get it NIST certified. This would be an extremely lengthy and expensive process, which doesn't seem worth the effort when there are multiple performant solutions available within the ecosystem that have already been validated and certified. I admit it would be cool though.

[markmsmith]

These rustls docs may be all that's needed to configure it for FIPS mode:
https://docs.rs/rustls/latest/rustls/manual/_06_fips/index.html

[alexcrichton]

From those docs it looks like Wasmtime might not need any changes at all? As an embedder of Wasmtime you could activate the crate feature and call the installation method, so would that work for your use case?

[markmsmith]

My (possibly wrong) understanding is that Wasmtime is implementing the wasi-http entrypoint, which is doing the TLS termination for inbound http requests and the wasm component that it's running (which might be compiled from golang instead of rust) is at the mercy of whatever Wasmtime did upstream for that crypto.