Copilot commented on code in PR #13548:
URL: https://github.com/apache/trafficserver/pull/13548#discussion_r3994051368
##########
src/iocore/net/SSLNetVConnection.cc:
##########
@@ -1283,6 +1283,18 @@ SSLNetVConnection::_sslStartHandShake(int event, int
&err)
SSL_set_verify(this->ssl, SSL_VERIFY_PEER, verify_callback);
+#if TS_USE_RPK
+ // Offer and/or pin RFC 7250 raw public keys when this next hop is
configured for them.
+ // Both are advertised alongside X.509, so a next hop that doesn't (yet)
support RPK -- a
+ // normal state during a rolling upgrade -- negotiates down to a
certificate exchange.
+ if (nps && (nps->client_rpk_enabled || nps->server_rpk_ca)) {
+ if (!ssl_client_setup_rpk(this->ssl, nps->client_rpk_enabled,
nps->server_rpk_ca)) {
Review Comment:
This installs the RPK pin on the connection, but the later
origin-session-cache lookup keys sessions only by SNI, SSL_CTX, and the normal
verify policy/properties. A resumed TLS 1.3 session does not present the peer
certificate/RPK, so this pin check is not rerun; after a pin/key change (or
when a cached session reaches a different backend sharing ticket keys), the
connection can therefore bypass `server_rpk_ca`. Include the trusted-key
set/fingerprint in the session-cache key or disable external session reuse for
RPK-configured hops.
##########
src/proxy/http/HttpSessionManager.cc:
##########
@@ -48,8 +48,20 @@ DbgCtl dbg_ctl_http_ss{"http_ss"};
bool
validate_session_origin_cert(HttpSM *sm, PoolableSession *session)
{
- return !session->is_multiplexing() ||
- validate_server_certificate_hostname(session->get_netvc(),
sm->get_outbound_sni_for_cert_verification());
+ if (!session->is_multiplexing()) {
+ return true;
+ }
+
+ NetVConnection *netvc = session->get_netvc();
+ if (origin_pinned_raw_public_key(netvc)) {
+ // A raw public key carries no SAN, so the next hop's pin set stood in for
the name check. That
+ // set belongs to the sni.yaml entry the outbound SNI selected, so this
session is only reusable
+ // for a request that would send the same SNI. Deliberately not gated on
the SNI match mask or
+ // on NAME being in verify_server_properties: the pin set is the whole of
what authenticated
+ // this origin.
Review Comment:
This accepts a pooled RPK-authenticated HTTP/2 session based only on the
SNI. If `server_rpk_ca` or its verify policy is changed by an SNI reload while
the SNI stays the same, the existing session was authenticated under the old
pin set and is still reused; a key revoked from the new pin set (including one
previously allowed under PERMISSIVE) can therefore continue serving requests
without a new handshake. Track the pin-set/policy generation or digest in the
pooled session and invalidate/mismatch it on reuse (and apply the same check to
the queued-connect path).
##########
src/proxy/http/ConnectingEntry.cc:
##########
@@ -98,7 +99,16 @@ ConnectingEntry::state_http_server_open(int event, void
*data)
auto event = CONNECT_EVENT_TXN;
void *event_data = new_session;
- if (!validate_server_certificate_hostname(new_session->get_netvc(),
(*entry)->get_outbound_sni_for_cert_verification())) {
+ NetVConnection *session_netvc = new_session->get_netvc();
+ // A raw public key origin was authenticated by the next hop's pin
set, which belongs to
+ // the sni.yaml entry the outbound SNI selected, so only a
transaction that would send the
+ // same SNI may join this session.
+ bool const acceptable =
+ origin_pinned_raw_public_key(session_netvc) ?
+ ServerSessionPool::validate_sni(*entry, session_netvc) :
+ validate_server_certificate_hostname(session_netvc,
(*entry)->get_outbound_sni_for_cert_verification());
Review Comment:
The queued-connect handoff repeats the same SNI-only validation, so it can
hand a pre-authenticated RPK session to a transaction after the configured pin
set or verify policy changed. That bypasses the new pin during the period
before the pooled session closes. Include the RPK pin-set/policy identity in
this handoff's compatibility check, or drain these sessions when the SNI
configuration changes.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
