quic: populate peer certificate details in QUIC connection info#45978
Open
bpalermo wants to merge 1 commit into
Open
quic: populate peer certificate details in QUIC connection info#45978bpalermo wants to merge 1 commit into
bpalermo wants to merge 1 commit into
Conversation
QuicSslConnectionInfo stubbed every peer certificate accessor with empty values (TODO envoyproxy#23809), so peer certificate details of HTTP/3 connections (e.g. upstream access log fields) were always empty. The X509-based BoringSSL getters used by ConnectionInfoImplBase are not usable on QUIC's CRYPTO_BUFFER-based SSL object, so the peer certificate accessors in the base class are now routed through two protected virtual hooks (peerCertificate/peerCertificateChain) whose default implementation preserves the existing TCP TLS behavior. QuicSslConnectionInfo overrides the hooks by converting the CRYPTO_BUFFER peer chain to X509 once and caching it, and drops the stubs so all base class accessors work. Local certificate accessors remain unsupported on QUIC. This is also groundwork for QUIC client certificate authentication (envoyproxy#23809): once client certs are requested, XFCC and RBAC principals need these fields populated. Signed-off-by: Bruno Palermo <b@palermo.dev>
|
Hi @bpalermo, welcome and thank you for your contribution. We will try to review your Pull Request as quickly as possible. In the meantime, please take a look at the contribution guidelines if you have not done so already. |
This was referenced Jul 5, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Commit Message
quic: populate peer certificate details in QUIC connection info
Additional Description
Part 1 of re-introducing QUIC client certificate authentication (#23809, supersedes part of the
stale #40017). This PR is independently useful today: peer certificate details of upstream HTTP/3
connections (access log fields, header formatters) were always empty because
QuicSslConnectionInfostubbed every accessor.The X509-based BoringSSL getters used by
ConnectionInfoImplBaseare not usable on QUIC'sCRYPTO_BUFFER-based SSL object (they are guarded only by
assertand are undefined behavior on aTLS_with_buffers_methodSSL). Rather than duplicating all accessors with CRYPTO_BUFFER-safevariants (the approach in #40017, ~600 lines), the base class peer certificate accessors are
routed through two protected virtual hooks (
peerCertificate()/peerCertificateChain()) whosedefault implementations preserve the existing TCP TLS behavior exactly.
QuicSslConnectionInfooverrides the hooks by converting the CRYPTO_BUFFER peer chain to X509 once (cached, recomputed
if queried pre-handshake) and deletes the stubs, so all base class accessors and their existing
caching work unchanged.
validatedPeerIssuer()is served from the presented chain. Localcertificate accessors remain unsupported on QUIC (the local cert lives in the proof source, not
the SSL object).
Follow-ups (separate PRs): upstream QUIC client certificate presentation, and server-side QUIC
mTLS (
require_client_certificate) via aVerifyCertChainoverride in the existingper-session
EnvoyTlsServerHandshaker.Risk Level
Low — the base class hook refactor is behavior-preserving for TCP TLS (default hook
implementations are the exact previous calls); QUIC accessors go from hardcoded-empty to
populated.
Testing
New
test/common/quic/quic_ssl_connection_info_test.ccperforming a real in-memory handshakeover
TLS_with_buffers_methodSSL objects (the same method QUICHE uses): full accessor matrixwith a client cert, no-cert case, pre-handshake query + recomputation, issuer-from-chain, and the
validated flag. Existing
//test/common/tls/...suite passes unchanged (guards the base classrefactor).
Docs Changes
N/A
Release Notes
Added a bug-fix changelog fragment.
Platform Specific Features
N/A