Skip to content

quic: populate peer certificate details in QUIC connection info#45978

Open
bpalermo wants to merge 1 commit into
envoyproxy:mainfrom
bpalermo:quic-conninfo-peer-certs
Open

quic: populate peer certificate details in QUIC connection info#45978
bpalermo wants to merge 1 commit into
envoyproxy:mainfrom
bpalermo:quic-conninfo-peer-certs

Conversation

@bpalermo

@bpalermo bpalermo commented Jul 5, 2026

Copy link
Copy Markdown

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
QuicSslConnectionInfo stubbed every accessor.

The X509-based BoringSSL getters used by ConnectionInfoImplBase are not usable on QUIC's
CRYPTO_BUFFER-based SSL object (they are guarded only by assert and are undefined behavior on a
TLS_with_buffers_method SSL). Rather than duplicating all accessors with CRYPTO_BUFFER-safe
variants (the approach in #40017, ~600 lines), the base class peer certificate accessors are
routed through two protected virtual hooks (peerCertificate() / peerCertificateChain()) whose
default implementations preserve the existing TCP TLS behavior exactly. QuicSslConnectionInfo
overrides 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. Local
certificate 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 a VerifyCertChain override in the existing
per-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.cc performing a real in-memory handshake
over TLS_with_buffers_method SSL objects (the same method QUICHE uses): full accessor matrix
with 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 class
refactor).

Docs Changes

N/A

Release Notes

Added a bug-fix changelog fragment.

Platform Specific Features

N/A

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>
@bpalermo bpalermo requested a deployment to external-contributors July 5, 2026 01:29 — with GitHub Actions Waiting
@repokitteh-read-only

Copy link
Copy Markdown

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.

🐱

Caused by: #45978 was opened by bpalermo.

see: more, trace.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant