The DOMino Effect: Detecting and Exploiting DOM Clobbering Gadgets via Concolic Execution with Symbolic DOM

STEK Sharing is Not Caring: Bypassing TLS Authentication in Web Servers using Session Tickets

Speakers: Sven Hebrok (Paderborn University); Tim Leonhard Storm (Paderborn University); Felix Matthias Cramer (Paderborn University); Maximilian Radoy (Paderborn University); Juraj Somorovsky (Paderborn University)

Conference: USENIX Security

YouTube: https://www.usenix.org/conference/usenixsecurity25/presentation/hebrok

Overview

This article delves into a critical security vulnerability discovered in how modern web servers handle TLS session resumption, particularly in virtual hosting environments. Researchers from Paderborn University, Sven Hebrok, Tim Leonhard Storm, Felix Matthias Cramer, Maximilian Radoy, and Juraj Somorovsky, presented their findings on "session ticket confusion" attacks. These attacks exploit the shared use of Session Ticket Encryption Keys (STEKs) across multiple virtual hosts, leading to the bypass of both server and client authentication in TLS connections.

The talk highlights a fundamental flaw where a server, designed to optimize performance by reusing cryptographic session parameters, inadvertently compromises the isolation between distinct virtual hosts. This can allow an attacker to trick a server into serving content from a different, potentially privileged, domain than originally intended, even when the initial connection was securely authenticated. The implications are far-reaching, affecting widely used web server software like Apache, nginx, (Open)LiteSpeed, and Caddy, as well as major Content Delivery Networks (CDNs) such as Fastly, DDoS-Guard, and Cloudflare.

The significance of this research lies in its exposure of critical security gaps in modern virtual hosting architectures, which are foundational to much of the internet's infrastructure. By demonstrating practical attacks and conducting large-scale evaluations, the researchers underscore the urgent need for developers and operators to re-evaluate their TLS configurations and session management strategies to prevent authentication bypasses and privilege escalation. The findings challenge the implicit security assumptions surrounding TLS session resumption in complex multi-domain environments.

Background

Transport Layer Security (TLS) is the cornerstone of secure internet communication, providing confidentiality, integrity, and authenticity for data exchanged between clients and servers. This security is established through a TLS handshake, where cryptographic parameters are negotiated, shared secrets are established, and parties authenticate each other, typically through server certificates. Less commonly, client authentication can also be employed, where clients present their own certificates to the server, mirroring the server authentication process.

Modern web infrastructure heavily relies on virtual hosting, a practice where a single physical server hosts multiple distinct domains. This is driven by the scarcity of IPv4 addresses and the need to optimize resource utilization. To differentiate between domains, clients include the Server Name Indication (SNI) in their initial ClientHello message, allowing the server to present the correct TLS certificate. Additionally, the HTTP Host header further specifies the intended domain at the application layer. Robust isolation between these virtual hosts is paramount to prevent security vulnerabilities. Content Delivery Networks (CDNs) extensively use virtual hosting to serve numerous customers from geographically distributed edge servers, often sharing infrastructure.

To mitigate the computational overhead of repeated full TLS handshakes, session resumption mechanisms were introduced. One prevalent method is session tickets, where a server encrypts a TLS context (including session keys) using a symmetric Session Ticket Encryption Key (STEK) and issues this ticket to the client. Upon a subsequent connection, the client presents the ticket, allowing the server to decrypt it and resume the session without a full handshake or certificate re-validation. While this stateless approach boosts performance, it introduces new security considerations.

Previous research has highlighted potential risks associated with session resumption. In 2015, Delignat-Lavaud and Bhargavan demonstrated isolation flaws in session resumption with session IDs, leading to server authentication bypasses. Subsequent work by Springall et al. (2016) and Valsorda (2017) explored the impact of session tickets on forward secrecy and overall session compromise due to improper STEK protection. Hebrok et al. (2023) further confirmed these dangers, identifying weak or reused STEKs in large-scale analyses. However, these prior attacks primarily focused on confidentiality. The present work extends this investigation to the authenticity guarantees of TLS, specifically in the complex landscape of virtual hosting and shared STEKs.

Key Findings

The research systematically analyzed the security implications of session ticket-based resumption, leading to two primary research questions (RQ1 and RQ2) and significant discoveries:

1. Novel Authentication Bypass Attacks (RQ1): The authors introduced two novel "session ticket confusion" attacks that undermine TLS authentication guarantees:

• Server Authentication Bypass: An extension of previous work, enabling a TLS Machine-in-the-Middle (MitM) attack where an attacker redirects a victim's resumed connection to their own virtual host on a shared CDN, effectively intercepting sensitive data.
• Client Authentication Bypass: A novel attack demonstrating how session tickets can be misused to bypass TLS client authentication, leading to privilege escalation within virtual hosting environments by accessing restricted domains without a valid client certificate.

1. Vulnerabilities in Open-Source Implementations (RQ2): A thorough analysis of four popular open-source web server implementations confirmed real-world applicability:

• All four tested servers – Apache, nginx, (Open)LiteSpeed, and Caddy – were found vulnerable to client authentication bypasses.
• LiteSpeed was uniquely vulnerable even without session resumption, allowing client authentication bypass simply by manipulating the HTTP Host header during an initial full handshake.
• Apache (CVE-2025-23048) and nginx (CVE-2025-23419) were assigned CVEs for their identified vulnerabilities.

1. Large-Scale Real-World Impact: A sophisticated methodology for large-scale scanning revealed widespread vulnerabilities in deployed virtual hosting environments:

• Six distinct clusters of providers were identified as susceptible to server authentication bypasses.
• Prominent CDNs and DDoS protection services, including Fastly, DDoS-Guard, and Variti, were among the affected providers. Fastly specifically fixed an issue found during a pre-scan phase.
• A separate client authentication bypass was discovered in Cloudflare's API Shield, which was subsequently fixed by Cloudflare disabling session resumption when using mTLS.

1. Discovery of Unrelated Cloudflare SaaS Vulnerability: During the large-scale scan, an additional, unrelated vulnerability was found in Cloudflare's SaaS offering. This flaw allowed SaaS providers to perform a TLS-MitM attack on their customers by internally forwarding requests to the SaaS provider's backend, even though the correct certificate for the customer's domain was presented. Cloudflare confirmed this issue in a deprecated enterprise version.

1. Inconsistent Server Behavior: The analysis highlighted significant inconsistencies in how different web servers, and even different TLS versions within the same server (e.g., TLS 1.2 vs. TLS 1.3), handle session resumption and virtual host isolation. This complexity contributes to the prevalence of misconfigurations and vulnerabilities.

Technical Deep Dive

The core of the "session ticket confusion" vulnerabilities lies in the shared use of Session Ticket Encryption Keys (STEKs) across different virtual hosts within a single server instance or even across a CDN's infrastructure. While STEK sharing can improve performance by allowing clients to resume sessions even when routed to different nodes, it introduces a critical security risk if the server fails to properly re-validate the intended destination domain during resumption.

The attacks leverage the fact that an abbreviated TLS handshake using a session ticket does not involve the exchange or re-validation of server or client certificates. Instead, the server decrypts the ticket, retrieves the previously negotiated session state, and proceeds directly to encrypted communication. If the server only relies on the ticket for identity and fails to cross-reference it with other indicators like SNI or the HTTP Host header, an attacker can manipulate these headers to confuse the server.

Server Authentication Bypass

This attack scenario, an extension of previous work, focuses on enabling a TLS Machine-in-the-Middle (MitM) attack.

• Victim Behavior: A client (victim) connects to a legitimate website, a.com, hosted on a CDN (e.g., on IP 1). During this initial full handshake, the client validates the server's certificate for a.com and receives a session ticket. Later, the victim attempts to reconnect to a.com, presenting the session ticket for resumption.
• Attacker Capabilities: The attacker owns another domain, e.com, also hosted on the same CDN infrastructure, potentially on a different IP (e.g., IP 2). Crucially, the CDN shares the same STEK between a.com and e.com. The attacker has the ability to reroute the victim's network traffic at the IP layer (e.g., through DNS manipulation or BGP hijacking) such that the resumption request for a.com is directed to IP 2, where e.com is hosted.
• Attack Description: When the victim's resumed connection for a.com arrives at IP 2, the server (configured for e.com) decrypts the session ticket (issued for a.com) using the shared STEK. If the server on IP 2 then ignores the SNI and HTTP Host header (which still specify a.com) and instead serves content based on its own configuration (e.com), the attacker achieves a MitM. The victim's browser, having already validated the certificate in the initial handshake and seeing a successful resumption, will accept the connection as legitimate for a.com but will be receiving content from e.com.
• Impact: The attacker can intercept the victim's plaintext requests, including sensitive information like session cookies and passwords. They can also inject malicious content, such as Cross-Site Scripting (XSS) payloads, into the victim's browser without breaking the TLS authentication chain.

Client Authentication Bypass

This novel attack focuses on privilege escalation by circumventing TLS client authentication.

• Victim Behavior: A server hosts two virtual hosts: a.com (accessible to the attacker, possibly requiring client authentication for which the attacker has a valid certificate) and b.com (restricted, requiring client authentication for which the attacker does not have a valid certificate).
• Attacker Capabilities: The attacker can perform TLS connections to the server. They first connect to a.com and obtain a valid session ticket.
• Attack Description: The attacker then attempts to resume the session ticket, but this time, they manipulate both the SNI and Host header to specify b.com. If the server accepts and resumes the ticket, it effectively skips the client certificate re-validation step for b.com because the ticket was successfully decrypted. The server then serves the restricted content of b.com to the attacker, who should not have access.
• Impact: This results in an authentication bypass and privilege escalation, allowing unauthorized access to restricted resources or functionalities.

Open-Source Implementation Analysis

The researchers rigorously tested four prominent web servers: Apache, Caddy, nginx, and (Open)LiteSpeed, in both TLS 1.2 and TLS 1.3 configurations, with various SNI and Host header manipulations.

• Apache: Generally robust against server authentication bypasses. It typically rejects tickets if the SNI doesn't match the issuer or returns a 421 Misdirected Request if the Host header is inconsistent. However, in TLS 1.3 (with SSLStrictSNIVHostCheck disabled, which is default), it was vulnerable to client authentication bypass if the SNI was omitted and the accessible host was the default.
• Caddy: Requires SNI to be present. It was vulnerable to client authentication bypass if both SNI and Host header were set to the inaccessible domain during resumption, despite having a default setting to prevent Host header manipulation in full handshakes.
• nginx: Exhibited a critical flaw by largely ignoring the SNI and relying primarily on the Host header to determine content. This made it vulnerable to client authentication bypasses in TLS 1.3 if the SNI was set to the inaccessible domain or omitted entirely, and the Host header was set to the inaccessible domain. The nginx (strict SNI) configuration only partially mitigated this by rejecting missing SNI, but not a manipulated SNI.
• (Open)LiteSpeed: Showed the most egregious behavior. While it only resumed tickets if the resumption SNI matched the issuance SNI, it determined the served content based solely on the Host header. This allowed client authentication bypass even without session tickets; simply changing the Host header in a full handshake was sufficient to access protected content.

Inconsistencies and Standard Weaknesses

A notable finding was the significant inconsistencies:

• Between Web Servers: No two servers behaved identically, especially regarding when to resume tickets and how to handle SNI/Host header mismatches.
• Within Web Servers: Inconsistencies were observed between TLS 1.2 and TLS 1.3 implementations, with TLS 1.3 often exhibiting higher susceptibility. Behavior also varied depending on whether the accessible host required client authentication.

These inconsistencies are partly explained by ambiguities and weaknesses in the TLS standards themselves:

• RFC 6066 (TLS 1.2): Mandates that servers must not accept session resumption under a different hostname than the initial SNI.
• RFC 8446 (TLS 1.3): Explicitly removes the direct linkage between SNIs and sessions, tying resumption to the certificate presented during the initial handshake. It includes a "performance optimization" to match SNIs but places this responsibility primarily on the client, overlooking active attacker redirection or malicious clients. Crucially, it claims "there is no need for the server to associate an SNI value with the ticket" and "normally, there is no reason to expect that different servers covered by a single certificate would be able to accept each other’s tickets" – assertions that are directly contradicted by modern CDN and virtual hosting realities where STEKs are widely shared across multiple certificates.
• TLS/HTTP Interplay: The discrepancy between TLS's SNI and HTTP's Host header is a persistent issue. Servers often fail to validate that these two hostname indicators match, leading to broken authentication, even though TLS only authenticates the SNI hostname. RFC 8446 also mandates that only the resumption SNI be exposed to application layers, emphasizing the need for robust authentication throughout the entire request, not just within the TLS layer.
• Misconfigurations: The concept of a "default host" in virtual hosting, which handles undefined hostnames, is a common source of misconfiguration that can enable these authentication bypasses.

Demo / Proof of Concept

While this research is presented as a peer-reviewed paper rather than a live conference talk with a traditional demo, the authors provided extensive practical validation through two distinct evaluation phases that serve as robust proofs of concept: the Open-Source Analysis and the Large-Scale Real-World Evaluation.

Open-Source Analysis

For the open-source analysis, the researchers set up controlled environments for Apache, Caddy, nginx, and (Open)LiteSpeed. Each server was configured to host at least two different virtual hosts: an attacker-accessible host (I) and a potentially restricted resumption host (R). They systematically varied configurations, including whether hosts were default, used the same or different STEKs (where supported), and operated under TLS 1.2 or TLS 1.3.

The methodology involved:

1. Retrieving a session ticket for the initial host (I).
2. Attempting to resume the session, deliberately manipulating the SNI and Host header to point to either the issuing host, the resumption host (R), or omitting the SNI.
3. Observing the server's behavior: whether the ticket was resumed, if a full handshake fallback occurred, or which virtual host's content was served (or if an HTTP error like 403 or 421 was returned).

These controlled experiments successfully demonstrated the client authentication bypasses in all four implementations, with specific conditions for each. For instance, LiteSpeed was shown to be vulnerable to client authentication bypass simply by altering the Host header in the initial full handshake, negating the need for session resumption for this specific vulnerability. Apache and nginx were found to have vulnerabilities primarily in TLS 1.3 under specific SNI/Host header manipulation scenarios.

Large-Scale Real-World Evaluation

To assess the broader impact, the researchers performed a large-scale scan targeting server authentication bypasses, as client authentication is less prevalent on public-facing servers. Their methodology for this involved:

1. Candidate Creation: Using the Tranco Top 1M list of popular domains, they resolved IP addresses and probed for TLS and session ticket support. They also expanded their domain list using Subject Alternative Names (SANs) from encountered certificates. Servers were grouped by common 4-byte STEK prefixes (an identifier within the ticket) to identify candidates likely sharing STEKs.
2. Resumption Attempts: For each candidate domain on an issuing IP, they randomly selected up to 10 IPv4 and 10 IPv6 addresses (sharing the STEK prefix but not hosting the original domain) to attempt ticket resumption. They emulated the attack by sending an HTTP GET / request with the original domain's SNI and Host header to the issuing IP to get a ticket, then re-sent the same request with the ticket to the selected resumption IPs.
3. Response Evaluation: Responses were classified as secure (ticket rejected, HTTP error like 421, identical content/redirects) or requiring further analysis. For differing HTTP bodies, they used normalized Levenshtein ratio to compare the resumed content with the initial content and content from other domains hosted on the resumption IP.
4. Manual Review & Clustering: Candidates with low initial-to-resumed similarity and high resumed-to-other-origin similarity were manually reviewed. Results were clustered by Autonomous System (AS) or CDN provider.

This large-scale scan, utilizing tools from the ZMap Project (ZDNS for resolution, ZMap for port probing, ZGrab2 for TLS handshakes and HTTP requests), processed millions of domains and sampled nearly 60 million pairs. It identified six clusters of vulnerable providers for server authentication bypasses, including DDoS-Guard and Variti. Crucially, it uncovered a server authentication bypass in Fastly's CDN service during a preliminary scan, which Fastly promptly addressed by binding tickets to the issuing certificate.

Furthermore, the methodology inadvertently revealed a vulnerability in Cloudflare's SaaS offering, unrelated to session tickets. This flaw allowed SaaS providers to perform a TLS-MitM attack on their customers by routing traffic to the SaaS backend even when a customer's domain was requested on a shared SaaS IP. Cloudflare acknowledged this issue, stating it affects a deprecated enterprise version. For client authentication bypasses in CDNs, a manual evaluation of Google's Load Balancer, Azure App Gateway, and Cloudflare's API Shield found Cloudflare to be vulnerable, leading to its fix.

These extensive evaluations provide compelling evidence of the practicality and widespread nature of the identified session ticket confusion vulnerabilities, serving as powerful proofs of concept for the theoretical attacks.

Defensive Implications

The core issue highlighted by these vulnerabilities is the inconsistent isolation of virtual hosts during TLS session resumption. To address this, developers and operators must ensure that the identities and authentication contexts established during the initial TLS handshake are rigorously maintained throughout any resumed sessions. This requires a fundamental shift in how session tickets are managed and validated.

Countermeasures for Server Authentication Bypass

To prevent server authentication bypasses, the most critical recommendation is to bind the session ticket to the server certificate chain.

• Mechanism: When a server issues a session ticket, it should include cryptographic material representing the entire certificate chain presented during that initial handshake within the ticket's protected context.
• Resumption Validation: Upon resumption, the server must decrypt the ticket and verify that the certificate chain currently in use for the requested virtual host exactly matches the chain recorded in the ticket.
• Action on Mismatch: If there is any mismatch in the certificate chain, the server must not resume the session. Instead, it should force a full TLS handshake, presenting the current certificate to the client. This empowers the client to re-validate the server's identity and decide whether to trust the new certificate, thus preventing an attacker from transparently redirecting traffic to a different, potentially malicious, virtual host.

Countermeasures for Client Authentication Bypass

For client authentication bypasses, the focus is on re-validating the client's identity during resumption.

• Mechanism 1 (Storing Client Certificate): The server should store the client certificate presented during the initial handshake within the session ticket. During resumption, the server can then retrieve this certificate and re-validate it against its current authentication rules for the requested virtual host. This ensures that the client's access privileges are still valid for the resumed session.
• Mechanism 2 (Binding to Authentication Rules): Alternatively, the server could bind the session ticket to the specific authentication rules (e.g., required Certificate Authorities, policies) that the client certificate successfully passed during the initial handshake. If the resumption attempt targets a virtual host with different or more stringent authentication rules, the server should fall back to a full handshake, requiring the client to re-authenticate. While potentially easier to implement, this might incur a performance penalty if rule sets frequently differ.

Considered Alternatives and OpenSSL Implementation

The researchers also considered binding tickets to the SNI, but rejected it as a complete solution because fallback mechanisms in multi-server scenarios and intentional session resumption across hostnames (within the same certificate) could still lead to bypasses.

For practical implementation, the authors explored OpenSSL 3.5. They recommend using OpenSSL's session context feature, an arbitrary 32-byte string, to bind tickets.

• Server Authentication: The server certificate chain (or a hash of it) should be included in the session context.
• Client Authentication: The list of acceptable client certificates or a hash of the relevant authentication rules should be included in the session context.
• Caveats: The session context must be set on the SSL object (not the SSL_CTX object) and within the ClientHello callback (not the SNI callback) to ensure it's applied before OpenSSL decides whether to resume the session. Hashing large data (like certificate chains) is recommended due to the 32-byte limit of the context. The researchers also noted that OpenSSL's APIs can be unintuitive and prone to misuse, as they often don't throw errors for incorrect usage, underscoring the need for misuse-resistant APIs from library maintainers.

General Best Practices

Beyond specific ticket binding, several general defensive measures are crucial:

• Strict Hostname Validation: Web servers must rigorously validate that the SNI provided in the TLS layer matches the HTTP Host header at the application layer, especially during session resumption.
• Careful Virtual Host Configuration: Operators of virtual hosting environments and CDNs must carefully configure "default hosts" and ensure that misdirected or improperly routed requests do not inadvertently lead to authentication bypasses.
• Regular Audits: Conduct regular security audits of TLS configurations and session management practices, particularly in complex multi-tenant or CDN environments.

By implementing these countermeasures, organizations can significantly enhance the security posture of their virtual hosting environments and ensure that the performance benefits of TLS session resumption do not come at the cost of compromised authentication.

Key Takeaways

• Shared STEKs are a Critical Risk: The common practice of sharing Session Ticket Encryption Keys (STEKs) across virtual hosts or CDN nodes creates "session ticket confusion" vulnerabilities.
• Authentication Bypasses are Practical: Both server and client authentication in TLS can be bypassed by exploiting these confusion vulnerabilities, enabling TLS-MitM attacks and privilege escalation.
• Major Software and CDNs Affected: Widely used web servers (Apache, nginx, Caddy, (Open)LiteSpeed) and prominent CDNs (Fastly, DDoS-Guard, Cloudflare) were found vulnerable, demonstrating widespread impact.
• TLS 1.3 More Susceptible: TLS 1.3 implementations often exhibited higher susceptibility to these issues compared to TLS 1.2, partly due to ambiguities in the standard regarding SNI-session linkage during resumption.
• Robust Ticket Binding is Essential: To defend against these attacks, session tickets must be cryptographically bound to the full server certificate chain and, for client authentication, to the client certificate or its associated authentication rules.
• OpenSSL API Misuse: Implementing secure session management with OpenSSL can be challenging due to non-intuitive APIs that can be misused without error, highlighting a need for more misuse-resistant library designs.

About the Speaker(s)

The research was conducted by Sven Hebrok, Tim Leonhard Storm, Felix Matthias Cramer, Maximilian Radoy, and Juraj Somorovsky, all affiliated with Paderborn University. They are researchers specializing in system security, with a focus on cryptographic protocols like TLS and their practical implications in real-world deployments.