Expose negotiated TLS metadata for QUIC connections

[iadev09]

Summary

Quinn's rustls HandshakeData already exposes ALPN (protocol) and SNI
(server_name), and Connection::peer_identity() exposes peer certificates.
However, there does not seem to be a public way to read the negotiated TLS
protocol version or cipher suite for a QUIC connection.

For HTTP/1.1 and HTTP/2 over TCP, server integrations using rustls can expose
request metadata such as:

• SSL_PROTOCOL
• SSL_CIPHER
• client certificate subject/issuer

For HTTP/3 over Quinn, the same server can expose client certificates through
peer_identity(), and can infer TLS 1.3 because QUIC requires it, but cannot
expose the negotiated cipher suite.

Use Case

Edge/server frameworks often want H1/H2/H3 request-context parity. For example,
CGI/FastCGI/PHP-style environments commonly expose TLS metadata to application
code. With Quinn today, the HTTP/3 path cannot fill SSL_CIPHER without
reaching into Quinn/rustls internals.

The use case is connection observability and H1/H2/H3 server-framework metadata parity.

The cipher suite is the practical missing piece. Exposing the TLS protocol
version as well would make the TLS metadata complete and avoid special-casing
QUIC as "always TLS 1.3" in server integrations.

Possible Shape

Would Quinn be open to exposing negotiated TLS metadata in rustls
HandshakeData, for example:

pub struct HandshakeData {
    pub protocol: Option<Vec<u8>>, // ALPN
    pub server_name: Option<String>,  
    pub protocol_version: Option<rustls::ProtocolVersion>,
    pub negotiated_cipher_suite: Option<rustls::CipherSuite>,
}

[djc]

I don't think we want to expose rustls-specific type in the HandshakeData type (especially because the crypto::Session API was designed to cover more than just TLS -- like maybe Noise for example), but in principle it should be fine to add more fields to it, as long as the fields can be defined in a reasonably generic manner.

[Ralith]

Two strategies we've used elsewhere:

• Encode the data into a simple primitive form that can represent any reasonable use
• Use Box<dyn Any> around a crypto session specific type and let the caller, who presumably knows what crypto layer they configured, downcast.

I haven't thought very hard about this, but my guess would be the latter makes more sense here, because other crypto layers might not have those specific concepts.

[djc]

Actually something like Noise probably does have both a version and some kind of suite.

[Ralith]

Do they have sufficiently similar encodings? There's also quinn-plaintext, which certainly has no such thing.

[iadev09]

let version = conn.protocol_version();
let cipher = conn.negotiated_cipher_suite();

This would be enough to provide access to the negotiated values without defining
an exposed final framework-level abstraction.

Downstream integrations usually normalize these values into their own context
and export them to upstreams in the upstream's expected context.
Also owned type might be used in both TCP and UDP pipeline pathes.

Downstream should already combine this information with conn.peer_identity() to make this usefull

SNI may already be read from rustls HandshakeData in a separate code path.

But each call to conn.handshake_data() constructs a new HandshakeData value.

Adding the cipher suite to rustls HandshakeData would let downstream
integrations optimize their own calls by reading the metadata once.

conn.protocol_version()
conn.negotiated_cipher_suite()

Or, if direct calls like these can be made cheap, like they are in the TCP/rustls
path, that would also work well.

How these calls should be handled most efficiently in the API is Quinn's decision

[djc]

I don't see a clear answer to the question of what types these values might/should have in your comment.

[iadev09]

Concrete value types would match the rustls/TCP path.

rustls::ProtocolVersion
rustls::CipherSuite

For the cipher suite I mean the wire enum returned by:
conn.negotiated_cipher_suite().map(|suite| suite.suite())

SupportedCipherSuite not required.

[djc]

That does not address the concerns raised in earlier comments.

[iadev09]

My boundary in this issue is server/edge metadata export. Edge servers will already export them as string or bytes at their own itegrations.

If rustls-specific types do not fit Quinn's API principles here, string values
would still satisfy that use case.

TLSv1.3
TLS_AES_256_GCM_SHA384

[Ralith]

A human-readable string is a rather strange encoding. Have you considered the options proposed in #2662 (comment)?

[iadev09]

Thank you giving me one more word, to tell the truth, any type which i can use any From impl of CipherSuite that i can reproduce with (The Prestige 🕊️<🕊️ ) , even an u16 helps me to have an owned protocole agnostic (TCP < QUIC) compatibile type while keeping respect of Quinn's norms.

Because this data will be fetched and mutate the request before the pipline , once but in every conneciton - ironically for performance goals..

Thank you.

[djc]

Your comment does not help me understand you better.

As @Ralith mentioned, his previous comment contained some clear suggestions.

[iadev09]

Sorry for the repetition. While editing my previous comment, I accidentally deleted the part where I said I preferred option (b), and ended up restating my demand-side concern in the issue comment instead.

I mean @Ralith's second strategy:

Use Box<dyn Any> around a crypto session specific type and let the caller,
who presumably knows what crypto layer they configured, downcast.

To avoid making you repeat the same concern again, what I understood is that the concern is specifically about putting rustls-specific types into the existing HandshakeData type, rather than about exposing any rustls-specific downcast payload at all. And this is because HandshakeData itself does not seem like the right place for TLS version and cipher-suite metadata.

So this is already just an observability metadata andto stay consistent with the current shape, one possible option would be a separate payload, for example:

fn handshake_info(&self) -> Option<Box<dyn Any>> 

with the rustls implementation returning something like:

pub struct HandshakeInfo {
    pub protocol_version: Option<rustls::ProtocolVersion>,
    pub negotiated_cipher_suite: Option<rustls::CipherSuite>,
}

The caller that configured rustls could then downcast to quinn::crypto::rustls::HandshakeInfo.

Even if I misunderstood that concern, the same shape could also avoid rustls types entirely:

pub struct HandshakeInfo {
    pub protocol_version: Option<u16>,        // TLS/IANA
    pub negotiated_cipher_suite: Option<u16>, // TLS/IANA
}

But u16 would be my second-best preference, not to re-produce the rsutls type in caller side.

[djc]

Let's just add protocol_version: Option<Box<dyn Any>> and cipher_suite: Option<Box<dyn Any>> to HandshakeData.

[iadev09]

Perfect.

Optimized for one call per connection, and a smaller API change.