Implement the ASGI TLS extension (#788)

[matssun]

Summary

Implements the ASGI TLS extension, exposing the connection's TLS details to ASGI applications under scope["extensions"]["tls"]. This closes the gap noted in #788: server-side mTLS (added in #574) already verifies client certificates, but the verified certificate was never communicated to the application.

Ticks the TLS box in the extensions tracker (#93).

What the application sees

On a TLS connection, scope["extensions"]["tls"] is a dict per the spec:

Key	Value
tls_version	negotiated version as an int (e.g. 0x0304), or None
cipher_suite	negotiated cipher suite as its 16-bit IANA id, or None
client_cert_chain	PEM-encoded client chain, leaf first; empty if none presented
client_cert_name	None
client_cert_error	None
server_cert	None

The tls key is present only on TLS connections, so apps detect support by its presence, exactly as the spec intends.

A few deliberate choices, kept minimal on purpose — happy to extend any of these if you'd prefer them in this PR:

• client_cert_name is None. Deriving the RFC4514 DN would mean pulling in an X.509 parser; the spec explicitly allows None and notes it duplicates client_cert_chain[0], which apps can parse themselves. No new dependency.
• server_cert is None. It is server-constant rather than connection-derived, so wiring it cleanly means threading the configured leaf through the acceptor. Left it out to keep this PR focused; easy to add if you want it.
• client_cert_error is always None. See the security note below — in Granian's model the app never sees a certificate that failed verification.
• ASGI only. RSGI/WSGI carry no standard TLS-extension shape, so they only accept-and-ignore the threaded value.

Implementation notes

• TLS metadata is captured once per connection, at accept time, after the handshake completes — read directly from the rustls ServerConnection on the accepted TlsStream. It is not recomputed per request.
• A small PeerTlsInfo trait does the extraction. The plain TcpStream / UnixStream impls return None, which monomorphizes away — so the non-TLS serving path is unchanged and pays nothing, and it keeps reusing the cached process-wide extensions dict. Only TLS connections build a per-connection extensions dict carrying tls.
• DER→PEM uses the pem crate already in the tree; no new dependencies.
• The session info is threaded through the existing worker target signature the same way addr_remote already is.

Security: the trust boundary is unchanged

This was the main thing I wanted to get right, so it's covered explicitly by tests:

• All client-certificate verification is still done by rustls before tls_listener yields the stream. A failed verification yields Err and no worker service is ever created — the application is never invoked. This code only reads already-verified, post-handshake state.
• Therefore a populated client_cert_chain is always a verified chain, which is why client_cert_error is always None (the app cannot observe a cert that failed verification). Tests assert that untrusted, missing, and revoked (CRL) certificates are all rejected at the handshake.
• The subtle case is covered too: with --ssl-ca but --no-ssl-client-verify (rustls allow_unauthenticated), a certificate is optional but a presented one must still be valid — an invalid presented cert is rejected, not surfaced as trusted.
• No new panic / unwrap paths on peer-controlled data; chain size is bounded by rustls. The extension exposes only the peer's own certificate — no key material, and server_cert is None.

Tests

New suite in tests/test_tls_extension.py (23 tests), plus client-CA / chain / rogue / revoked fixtures and mtls / crl switches in conftest.py:

• presence on TLS / absence on plaintext
• tls_version values for forced TLS 1.2 / 1.3
• mTLS single cert; leaf→intermediate chain ordering; PEM byte-exact round-trip to the original DER
• consistency across keep-alive, and per-connection isolation under concurrent distinct clients
• HTTP/2 and WebSocket (wss) paths
• trust boundary: untrusted cert rejected (mandatory and optional verify), missing cert rejected when required, revoked cert rejected via CRL (with a control proving it's the CRL, not an invalid cert, doing the rejecting)

Test results

Full suite, CPython 3.13, macOS:

$ pytest tests/test_tls_extension.py -q
23 passed

$ pytest tests -q
196 passed, 4 skipped

The 4 skipped tests are the same ones skipped on master.

Rust checks clean with the project config:

$ cargo fmt --all -- --check        # clean
$ cargo clippy --lib -- -D warnings -W clippy::pedantic ...   # clean

Follow-up (kept separate)

#788 also asks whether --ssl-client-verify without a --ssl-ca should be a hard error rather than a silent downgrade. That's a behaviour change, so I filed it separately as #853 to keep this PR focused. Worth noting this extension actually mitigates that footgun: an app can now fail closed when client_cert_chain is empty.

[matssun]

Rebased onto current master (2.8.1) — now a single linear commit, no conflicts.

The only conflict was in src/wsgi/serve.rs: since this PR was opened, the serve_fn! macro moved out of the per-protocol files into the shared src/serve.rs. That dedup means the TlsCtx parameter only needs threading in one place instead of two, so the diff is slightly smaller than before.

I also fixed a real bug in my own PR while revalidating: the two HTTP/2 cases in tests/test_tls_extension.py use httpx(http2=True), but the test dependency group only had httpx~=0.28, so h2 was never installed and those two tests would have failed in CI. Changed to httpx[http2]~=0.28. That was there from the start — apologies.

Local run on macOS arm64 / CPython 3.14: 199 passed, 4 skipped (the PGO-only ones), 0 failures. cargo fmt --check, cargo clippy --tests with the Makefile's allowance list, ruff check and ruff format --check all clean.

This implements #788, labelled enhancement/asgi. Happy to split it up or adjust the approach if that would make review easier — just let me know what you'd prefer.