Stream: git-wasmtime

Topic: wasmtime / issue #10089 Implement wasi-tls

Wasmtime GitHub notifications bot (Jan 23 2025 at 11:47):

badeend opened issue #10089:

wasi-tls has recently been accepted as a phase 1 proposal.

We'd like to start implementing this in wasmtime. There already exists some prior efforts:

• @dicej created a standalone WASI host with TLS support at: https://github.com/dicej/dotnet-wasi-tls
  - This implements a minimal subset of the draft spec.
  - Uses the native-tls crate.
• @jsturtevant modified the .NET runtime to use Joel's implementation at: https://github.com/dotnet/runtime/compare/main...jsturtevant:runtime:wasi-tls-2
  - This successfully runs their SqlClient.
• Based on Joel's work, I (@badeend) started integrating it into wasmtime itself: https://github.com/badeend/wasmtime/tree/wasi-tls
  - This too is just a minimal subset of the draft spec. Although the WIT in this branch has evolved slightly.
  - Uses the rustls crate.
  - The changes are part of the wasi-sockets interface, which is not the right place.
  - And some boilerplate:
  - threading through a new tls CLI flag
  - Change rustls from a wasi-http-only dependency to a workspace dependency.

---

My suggestion is to add a new standalone wasi-tls crate:

• under the /crates folder, similar to the other proposals.
• with its own world.wit and types.wit.
• that targets WASI v0.2 for the time being. Work on a v0.3 interface can happen in parallel in the future.
• that is completely experimental and therefore behind a tls flag.
• uses rustls for its implementation? (up for discussion, see next comment)

Thoughts?

---

CC @dicej @jsturtevant

Wasmtime GitHub notifications bot (Jan 23 2025 at 11:48):

badeend commented on issue #10089:

I did an inventory of the two most popular rust TLS crates to see how suitable they are to implement the draft spec:

rustls:

• doesn't support post-handshake authentication.
• supports programmatic client certificate selection, but the callback isn't async.
• supports programmatic peer certificate verification, but the callback isn't async.

native-tls:

• does not support TLS1.3 (yet)
• uses MacOS Secure Transport, which is deprecated and will likely never receive TLS1.3 support.
• does not support programmatic client certificate selection
• does not support programmatic peer certificate verification
• can't inspect the peer's certificate chain, only the leaf cert
• can't inspect ClientHello nor select server certificate & other configurations based on SNI
• can't read SNI submitted server name
• can't read negotiated TLS version
• can't read negotiated cipher suite
• can't configure ALPN ids on the server side
• can't configure cipher suites
• can't request mid-handshake client certificate on the server side
• doesn't support post-handshake authentication

From wasmtime's POV, rustls seems an obvious choice:

• it is already used by wasi-http,
• it is the most feature complete,
• allows us to quickly iterate on the WIT definitions. Most additions are simply hooking it up to the corresponding rustls methods.

Despite its shortcomings, from a Standards POV, native-tls has one important leg up:
Instant validation of portability goals against three different industry-standard back-ends (OpenSSL, SChannel, SecureTransport).
AFAIK, most of these shortcomings are of the native-tls crate itself and not of the underlying providers. Case in point: .NET's SSLStream is also built on top of SChannel & OpenSSL, yet _does_ support the desired features.

---

In the current stage the interface is still simple enough that it doesn't really matter which one we choose. I just wanted to throw it out there before we start sinking too much time into the integration of either option.

Wasmtime GitHub notifications bot (Jan 23 2025 at 16:57):

alexcrichton commented on issue #10089:

How unreasonable do you think it would be to support both rustls and native-tls? For example via compile-time Cargo features? It seems reasonable to have rustls as the default given its breadth of features but being able to showcase both in the same codebase would be a nice example for others looking to implement the proposal as well.

Last updated: Jan 24 2025 at 00:11 UTC