Skip to content

Fix global TLS ticket key use for certificate contexts - #13677

Open
RajaMuhammadAwais wants to merge 1 commit into
apache:masterfrom
RajaMuhammadAwais:fix-8734-global-ticket-key
Open

RajaMuhammadAwais wants to merge 1 commit into
apache:masterfrom
RajaMuhammadAwais:fix-8734-global-ticket-key

Conversation

@RajaMuhammadAwais

@RajaMuhammadAwais RajaMuhammadAwais commented Sep 14, 2026

Copy link
Copy Markdown
Contributor

Fix TLS Session Ticket Key Divergence Between Certificate Contexts

Related Issue

Fixes apache/trafficserver#8734.

Summary

Traffic Server can use different TLS session-ticket encryption keys depending on which certificate context handles a connection. This makes session-ticket resumption inconsistent across SNI/IP certificate contexts and can cause a deployment that shares Session Ticket Encryption Keys (STEKs) to split into groups of servers that can resume tickets only within their own group.

This change makes default certificate contexts use the globally managed TLS session-ticket key configuration instead of generating and retaining an independent random key block for every certificate context.

Problem

The TLS session-ticket callback selects its key block as follows:

  1. It looks up the certificate context associated with the local endpoint.
  2. If that context has a key block, it uses the context-specific key block.
  3. Otherwise, it falls back to SSLTicketKeyConfig::default_global_keyblock.

The certificate-context loader was creating a new random ticket-key block for every SNI/IP certificate context while enabling session tickets. These context-specific key blocks were stored in SSLCertContext::keyblock.

At the same time, the TSSslTicketKeyUpdate() API updates the global SSLTicketKeyConfig key block. It does not replace the independently stored key blocks attached to existing certificate contexts.

Therefore, a ticket-key update could succeed globally while connections selecting certificate contexts continued to encrypt and decrypt tickets with different, locally generated keys.

In a multi-server deployment using shared STEKs, this explains the issue's observed behavior: servers could resume sessions within subsets of the deployment but not across all servers.

Root Cause

The defect is the mismatch between these two ownership models:

  • Key updates: Global, through TSSslTicketKeyUpdate() and SSLTicketKeyConfig::default_global_keyblock.
  • Default certificate contexts: Independent random key blocks created during SSL context construction.

Because the context-specific key blocks were not updated by the global API, the API and the TLS ticket callback could operate on different key material.

What Changed

This patch changes ssl_context_enable_tickets() to perform only the SSL_CTX ticket-callback setup and ticket-option enablement. It no longer allocates a random key block during certificate-context construction.

When session tickets are enabled:

  • The TLS ticket callback is registered on the SSL_CTX.
  • TLS tickets remain enabled.
  • The default SSLCertContext is stored without a private ticket key block.
  • The callback consequently uses SSLTicketKeyConfig::default_global_keyblock.
  • Calls to TSSslTicketKeyUpdate() now affect all default SNI/IP certificate contexts consistently.

The change also removes the ticket-renewal metric increment that was previously performed once for each certificate context during context construction. Renewal metrics are now left to the actual global ticket-key configuration/update path.

Why This Is Safe

This preserves the existing global ticket-key behavior:

  • The global ticket key is still loaded/generated by SSLTicketKeyConfig.
  • Explicit ticket-key updates through TSSslTicketKeyUpdate() continue to replace the global key configuration.
  • The session-ticket callback remains registered on each SSL context.
  • Session tickets remain disabled when the relevant session-ticket configuration disables them.
  • Builds where TLS session-ticket support is unavailable retain the existing no-op success behavior.

The patch does not change:

  • Ticket format
  • Cryptographic algorithms
  • Key size
  • Key rotation order
  • OpenSSL callback behavior
  • TLS protocol negotiation

Files Changed

  • src/iocore/net/SSLUtils.cc

Validation Performed

The following checks were completed on the fork branch:

  • Configured Traffic Server with CMake and Ninja.

  • Built against OpenSSL 3.0.13.

  • Built the main traffic_server target successfully:

    [417/417] Linking CXX executable src/traffic_server/traffic_server
    

@bneradt

bneradt commented Sep 14, 2026

Copy link
Copy Markdown
Contributor

[approve ci]

@bryancall
bryancall requested a review from JosiahWI September 14, 2026 21:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

TLS session ticket get out of sync between servers

3 participants