Initial implementation of Wasi-tls (Transport Layer Security)

[jsturtevant]

fixes: #10089

This adds a crate that provides the Wasmtime host implementation for the wasi-tls API.
The wasi-tls world allows WebAssembly modules to perform SSL/TLS operations,
such as establishing secure connections to servers.

This initially implements it with rustls which was already included in the repository.

There are a few items that still need to be resolved but are not specially related to the implementation but wanted to start the review to make sure things moving in the correct direction.

• add a close-notify function to the wasi-tls wit in the proposal to properly close down the Add close function that allows for cleaning closing tls connection WebAssembly/wasi-tls#5
• resolve importing stable types into unstable features (Mismatch in stability attributes error in wit-parser when using Unstable attribute in wit wasm-tools#1995). Write now I have a workaround on a branch that is being used in rust cargo patch.

Thanks goes out to @badeend and @dicej as much of this was based on their prior work.

[badeend]

Looking great!

CI fails because Clippy being Clippy, and I suspect the build fails because there's some missing conditional compilation.

Aside from that, I;ve left behind some remarks:

[badeend]

Regarding this impl AsyncWrite for TcpStreams block and the impl AsyncRead for TcpStreams block below: I'm fine with them existing here, but AFAIK these have nothing to do with TLS right? If so, we could move them into the wasi-io subcrate at some point.

[jsturtevant]

correct, not specific to TLS it just enables passing wasi-io streams to libraries that require those traits (i.e. in this case the connect() method for rustls)

[jsturtevant]

The reason for this being the wit file directly is bytecodealliance/wasm-tools#1996 (comment)

[alexcrichton]

This looks great to me 👍

In terms of testing, would it be possible to also add a test (or multiple) that deal with the server-side as well. Ideally there'd either be a pre-generated cert check-in to the repo that they use or something generated at test-time perhaps per-test. That might help enable removing the dependency on example.com as well which has been flaky in the past, and while it's not the end of the world to have some flakiness it'd be best to insulate ourselves and have all the networking be purely local. Although I realize it's also good to test "is the system cert store actually used?" which necessarily requires external communication basially.

It might also be interesting, if local certs work, to test a variety of configurations related to invalid certificates to ensure that they do indeed all return an error instead of succeeding the authentication and such.

[jsturtevant]

In terms of testing, would it be possible to also add a test (or multiple) that deal with the server-side as well.

Just to clarify, you mean to implement a server similar to what is done on wasi-http but with certs? We are going to need this for more advance scenarios later so works for me. I'll get started on it here

[alexcrichton]

That's one route yeah, another being something similar to what wasi-sockets does where the client/server are both purely in-wasm and doens't require any external integration. The latter is a bit nicer from a "share this test suite in more places" perspective as well, but regardless I think either way is fine in the long run

[jsturtevant]

sounds good. We didn't add the server side parts to the wasi-tls spec yet but it shouldn't be to hard to do a minimal version as well now that the client side is done. @badeend wdyt?

[alexcrichton]

Oh I didn't look too closely at the tls bits here but if the server parts aren't implemented yet I don't mean to add more work here, so I think it's totally reasonable to land without that and plan to add more tests later too.

[badeend]

I'd prefer not to block this PR on the creation of server TLS connections from within a WASI guest. Creating server TLS connections brings along additional design complexity surrounding the handling of certificates & private keys from within a WASI guest.

If the goal is to reduce CI flakiness, we could also spin up a local TCP/TLS listener socket outside the guest, just before calling the test, and then connect to that from within the guest test.

[alexcrichton]

I think let's focus on getting this initial set landed in-tree for now (aka landing the wasm-tools fixes and integrating that here). This'll be a bit flaky without a local server but that can be a follow-up item to do after landing.

[jsturtevant]

(aka landing the wasm-tools fixes and integrating that here).

I tried pulling the fix (bytecodealliance/wasm-tools#2076) in from the main branch but looks like due to bytecodealliance/wasm-tools#2073, there were a few missing cases that need to be added to wit-bindgen and here. Would it be helpful to open PR's to stub those out or is there work being done on them? No rush/pressure, just want to be helpful if I can.

[alexcrichton]

Good point! I started the update a few days ago but didn't publish it -- #10314 -- I'll work on landing that once all the wasm-tools changes are in, but if you want to rebase on that it can give a preview of what things are likely to look like

[jsturtevant]

@badeend @alexcrichton We've merged all the outstand issues and I've rebased to bring in all the changes. I think this is ready for a final review. Thanks!

[alexcrichton]

I pushed a fix for the CI failure, and I double-checked and it looks like everything might actually work on s390x/riscv64 nowadays so I've updated to drop all the #[cfg] related to that. Otherwise looks good 👍