Add `native-tls` backend for wasi-tls #11064

badeend · 2025-06-17T18:30:23Z

During the initial wasi-tls implementation discussion, the suggestion was floated to support both rustls and native-tls. The initial/current implementation only supports rustls. This PR adds native-tls as an alternative TLS backend.

The default TLS provider remains rustls. Consumers can switch to the native-tls backend by enabling the corresponding feature flags and then use the newly created WasiTlsCtxBuilder::provider method. On the CLI, this is exposed as -S tls-provider=nativetls.

Adding this new backend immediately surfaced two bugs:

1. Improved compatibility of `test_tls_sample_application`

The test used to perform a "half-close" after sending the HTTP request. This is a TLS1.3+ feature, though Rustls & OpenSSL already supported it for TLS1.2 and lower. Technically, that makes them non-spec compliant, but they chose to align with the semantics of the underlying TCP connection. I suspect the TLS1.3 spec was updated to match what was already happening in reality.

Anyhow, SChannel does not support half-closed connections and so the read call after the close_output+shutdown failed. I've reordered the test to first perform the HTTP conversation and then do the TLS+TCP teardown.

2. Implement flushing on the AsyncWriteStream.

The AsyncWriteStream implementation was copied from the TCP equivalent, which doesn't need flushing. The TLS implementations do maintain an internal buffer, so the flush call needs to be hooked up. Without it, the test would hang after making the change mentioned above.

Misc: Reorganized wasi-tls folder

To make life easier for myself, I've shuffled some code around. I've isolated the rustls-specific bits from the rest of the implementation. The folder structure now looks like:

providers/*: The rustls & native-tls specific parts.
bindings.rs: The generated bindings.
host.rs: The host types + impls.
io.rs: WASI I/O conversion utility types.

CC: @jsturtevant

… from the rest of the implementation. - `client.rs`: The rustls parts. - `io.rs`: WASI I/O conversion utility types. - `host.rs`: The host types + impls. - `bindings.rs`: The generated bindings.

It used to perform a "half-close" after sending the HTTP request. This is a TLS1.3+ feature, though Rustls & OpenSSL already supported it for TLS1.2 and lower. Technically, that makes them non-spec compliant, but they chose to align with the semantics of the underlying TCP connection. I suspect the TLS1.3 spec was updated to match what was already happening in reality. Anyhow, SChannel does not support half-closed connections and so the `read` call after the `close_output+shutdown` failed. I've reordered the test to first perform the HTTP conversation and _then_ do the TLS+TCP teardown.

…implementation was copied from the TCP equivalent, which doesn't need flushing. The TLS implementations _do_ maintain an internal buffer, so the `flush` call need to be hooked up.

…nto native_tls # Conflicts: # Cargo.lock

alexcrichton · 2025-06-18T14:59:46Z

This all looks great to me, thanks again for working on this!

My only comment would be could this update CI checks to perform a build of the wasmtime-wasi-tls crate with some feature combinations? I'd be interested to see --no-default-features --features rustls and one for native-tls to ensure the crate can built with only one of the two enabled.

I'll file a separate PR to perform the vets as well.

… native_tls

…nto native_tls

badeend · 2025-06-19T08:56:36Z

Is this the right place to do that?

jsturtevant

Great finds in the bugs. LGTM me overall

jsturtevant · 2025-06-19T16:59:39Z

crates/wasi-tls/src/providers/mod.rs

+    } else if #[cfg(feature = "nativetls")] {
+        pub use NativeTlsProvider as DefaultProvider;
+    } else {
+        compile_error!("At least one TLS provider must be enabled.");


does it make sense to have to set two feature flags to enable the feature or should we provide a default to enable the feature or should we provide a default?

Also a bit confused in the way to set this up. Do I need to configure both feature flags (wasi-tls and nativetls or rusttls) and then also set the provider with wasi_tls_ctx: WasiTlsCtxBuilder::new().provider(provider).build(),?

rustls is part of the default feature. So by default, DefaultProvider will point to the rustls provider and there's no need to configure anything on the WasiTlsCtxBuilder.

Similarly, if you build with --no-default-features --features nativetls, then DefaultProvider will point to the native_tls provider and there's again no need to configure anything on the WasiTlsCtxBuilder.

The only reason to call WasiTlsCtxBuilder::provider is when the crate has been built with multiple providers and you want to switch between them at run time. This is what happens in e.g. the test suite and in the CLI code.

I've added some docs to clarify this.

alexcrichton

Yep that works 👍

alexcrichton · 2025-06-20T18:57:34Z

Hm ok so this is actually going to be kind of tricky. We test crates in CI with --all-features but we also test cross-compilations to various architectures, and native-tls on Linux wants OpenSSL which wants a system copy by default which isn't present for cross-compiled variants.

One option might be to have a feature such as openssl-vendored on the wasmtime-wasi-tls crate which builds a vendored copy of openssl-src. That way --all-features of that would be activated an OpenSSL would be built from source?

That's not an ideal option though IMO as ideally we wouldn't test native-tls by default and we'd instead have a dedicated job for just testin native-tls, but with --all-features that's not easy :(

badeend · 2025-06-22T09:45:22Z

How about moving /crates/wasi-tls/src/providers/native_tls.rs into a dedicated wasi-tls-nativetls crate and exclude that entire crate from the default test runs?

Edit: And set up a separate CI job to test wasi-tls-nativetls in isolation on a Linux, MacOS and Windows host.

Edit2: A downside of this approach is that the wasmtime CLI may not reference the wasi-tls-nativetls package anymore either.

alexcrichton · 2025-06-23T16:45:52Z

I think what you're proposing is probably the best option for now. You're right that it means that the CLI won't be easily buildable with native-tls, but that seems like a reasonable state of affairs for the time being and we can address that later if need be

prtest:full

…nto native_tls

badeend · 2025-06-26T20:39:49Z

Could you take a look at my latest changes? I've ran it with prtest:full and everything (except cargo vet) now succeeds.

badeend added 5 commits June 15, 2025 22:03

Reorganize the wasi-tls folder and isolate the rustls-specific bits…

6be0408

… from the rest of the implementation. - `client.rs`: The rustls parts. - `io.rs`: WASI I/O conversion utility types. - `host.rs`: The host types + impls. - `bindings.rs`: The generated bindings.

Add native-tls backend

181d138

Implement flushing on the AsyncWriteStream. The AsyncWriteStream …

d6f4f59

…implementation was copied from the TCP equivalent, which doesn't need flushing. The TLS implementations _do_ maintain an internal buffer, so the `flush` call need to be hooked up.

Switch to a model that uses runtime configuration.

97f4217

badeend requested review from a team as code owners June 17, 2025 18:30

badeend requested review from alexcrichton and removed request for a team June 17, 2025 18:30

Merge branch 'main' of https://github.com/bytecodealliance/wasmtime i…

46e76f3

…nto native_tls # Conflicts: # Cargo.lock

alexcrichton mentioned this pull request Jun 18, 2025

Add vets for wasi-tls native-tls provider #11066

Merged

badeend added 3 commits June 19, 2025 10:50

Check wasmtime-wasi-tls features in isolation.

4040567

Merge branch 'native_tls' of https://github.com/badeend/wasmtime into…

d8bee5f

… native_tls

Merge branch 'main' of https://github.com/bytecodealliance/wasmtime i…

b8d0572

…nto native_tls

jsturtevant approved these changes Jun 19, 2025

View reviewed changes

Clarify intended use of WasiTlsCtxBuilder::provider

240f561

alexcrichton approved these changes Jun 20, 2025

View reviewed changes

alexcrichton added this pull request to the merge queue Jun 20, 2025

github-merge-queue bot removed this pull request from the merge queue due to failed status checks Jun 20, 2025

badeend added 2 commits June 26, 2025 21:26

Split off native-tls implementation into separate crate

2f23518

Add a dedicated Ci job to test the native-tls backend.

4f2932e

prtest:full

badeend force-pushed the native_tls branch from 04487bf to 4f2932e Compare June 26, 2025 20:00

Merge branch 'main' of https://github.com/bytecodealliance/wasmtime i…

0e928d9

…nto native_tls

Update vets

cc23e74

alexcrichton enabled auto-merge June 27, 2025 14:31

alexcrichton added this pull request to the merge queue Jun 27, 2025

Merged via the queue into bytecodealliance:main with commit b85addc Jun 27, 2025
165 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Add `native-tls` backend for wasi-tls #11064

Add `native-tls` backend for wasi-tls #11064

Uh oh!

badeend commented Jun 17, 2025 •

edited

Loading

Uh oh!

alexcrichton commented Jun 18, 2025

Uh oh!

badeend commented Jun 19, 2025

Uh oh!

jsturtevant left a comment

Uh oh!

jsturtevant Jun 19, 2025

Uh oh!

badeend Jun 19, 2025

Uh oh!

alexcrichton left a comment

Uh oh!

Uh oh!

alexcrichton commented Jun 20, 2025

Uh oh!

badeend commented Jun 22, 2025 •

edited

Loading

Uh oh!

alexcrichton commented Jun 23, 2025

Uh oh!

badeend commented Jun 26, 2025

Uh oh!

Uh oh!

Uh oh!

Add native-tls backend for wasi-tls #11064

Add native-tls backend for wasi-tls #11064

Uh oh!

Conversation

badeend commented Jun 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

1. Improved compatibility of test_tls_sample_application

2. Implement flushing on the AsyncWriteStream.

Misc: Reorganized wasi-tls folder

Uh oh!

alexcrichton commented Jun 18, 2025

Uh oh!

badeend commented Jun 19, 2025

Uh oh!

jsturtevant left a comment

Choose a reason for hiding this comment

Uh oh!

jsturtevant Jun 19, 2025

Choose a reason for hiding this comment

Uh oh!

badeend Jun 19, 2025

Choose a reason for hiding this comment

Uh oh!

alexcrichton left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

alexcrichton commented Jun 20, 2025

Uh oh!

badeend commented Jun 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alexcrichton commented Jun 23, 2025

Uh oh!

badeend commented Jun 26, 2025

Uh oh!

Uh oh!

Uh oh!

Add `native-tls` backend for wasi-tls #11064

Add `native-tls` backend for wasi-tls #11064

badeend commented Jun 17, 2025 •

edited

Loading

1. Improved compatibility of `test_tls_sample_application`

badeend commented Jun 22, 2025 •

edited

Loading