Stream: git-wasmtime

Topic: wasmtime / issue #12102 Upgrade `wasmtime-wasi-tls` imple...

Wasmtime GitHub notifications bot (Dec 01 2025 at 10:28):

Aditya1404Sal opened issue #12102:

Feature

Implement WASI TLS Phase 2 following the simplified security-focused wit proposal from https://github.com/WebAssembly/wasi-tls/issues/13

Benefit

Phase 1 is unstable and only supports client-side TLS. This blocks WASI components from:

• Accepting incoming TLS connections (servers, proxies)
• Accessing connection metadata (cipher suite, peer certificates)
• Following modern async patterns aligned with Preview 2/3

Phase 2 adds server-side support with a simplified, security-first API that:

• Focuses on TLS 1.3 (modern security, 75%+ adoption)
• Removes problematic features (0-RTT replay attacks, suspension points)
• Uses linear async flow that naturally evolves to Preview 3's async/await
• Reduces API surface by ~40% while adding critical functionality

Implementation

Replace current Phase 1 WIT with Phase 2 proposal from https://github.com/WebAssembly/wasi-tls/issues/13

Key additions:

• Server resource with identity/ALPN/client-auth configuration
• Connection resource with cipher-suite, peer-certificate, close methods
• accept() for server-side handshakes
• Async pattern: finish() + subscribe() (Preview 2) -> async finish() (Preview 3)
• Unified rustls/native-tls provider architecture with client/server separation

Security benefits:

• No suspension points = no deadlock/state machine complexity
• TLS 1.3 focus = modern ciphers, forward secrecy
• Linear flow = easier auditing, fewer vulnerabilities

Alternatives

Nonexistent

Wasmtime GitHub notifications bot (Dec 01 2025 at 10:38):

Aditya1404Sal commented on issue #12102:

Note: I'm currently working on a reference implementation for this proposal and will be opening a PR shortly. Creating this issue first to document the feature request and facilitate discussion before the PR review.

Wasmtime GitHub notifications bot (Dec 01 2025 at 12:13):

tschneidereit commented on issue #12102:

I would strongly recommend seeing more of the discussion of the spec change proposal through before implementing this, since I could see things changing substantially. In particular, the last paragraph in Joel's comment on guest language APIs might well result in big changes.

(As an aside, the term "phase" as used here is a bit confusing, as the WASI standardization process uses that term to describe stabilization stages of a proposal. I guess what you're talking about is something like a proposed API change for wasi-tls.)

Wasmtime GitHub notifications bot (Dec 01 2025 at 12:37):

Aditya1404Sal commented on issue #12102:

Thanks for the feedback and clarification on the terminology! You're right, I should've framed this as an "API redesign proposal" rather than "Phase 2." (Apologies for the confusion)

I understand the concern regarding the spec consensus, especially given Joel's comments about guest language API compatibility.

I'll review the existing Research into .NET and NodeJS's APIs to better understand the compatibility requirements.

Are there specific aspects of the API design where prototyping or analysis would be most helpful for moving the discussion forward?

Wasmtime GitHub notifications bot (Dec 01 2025 at 12:45):

tschneidereit commented on issue #12102:

Are there specific aspects of the API design where prototyping or analysis would be most helpful for moving the discussion forward?

At this point I think the discussion is more important than prototyping, honestly

Wasmtime GitHub notifications bot (Dec 01 2025 at 16:42):

alexcrichton added the wasi:impl label to Issue #12102.

Last updated: Dec 06 2025 at 06:05 UTC