Hardening Session Ticket Encryption Key Rotation in Distributed Edge Proxies

TLS session resumption is one of the few places in modern network engineering where a performance optimization directly erodes a security guarantee. The Session Ticket Encryption Key (STEK) sits at that intersection: it lets edge proxies skip full cryptographic handshakes for returning clients, but it does so by creating a single symmetric key that unlocks every session encrypted under it. Get the key management wrong—and production teams routinely do—and a passive adversary holding weeks of recorded ciphertext suddenly has the decryption oracle they need.

This article covers how STEKs work at the protocol level, what the research record says about how they fail in practice, how to design an automated multi-key rotation loop that survives Anycast routing and global key propagation windows, and how TLS 1.3’s PSK model changes the threat surface without eliminating it.

---

1. The Stateless Session Ticket Model

A standard TLS 1.3 handshake requires at least one round-trip before application data can flow. For a mobile client hitting an API gateway over a high-latency path, that overhead is measurable. The session ticket mechanism, defined for TLS 1.2 in RFC 5077 and adapted into TLS 1.3’s Pre-Shared Key (PSK) resumption model in RFC 8446, offloads session state to the client to remove that cost.

The flow is straightforward:

1. After a completed full handshake, the server derives a resumption secret and encrypts it using the STEK—a symmetric key held only by the server—producing an opaque blob called a session ticket.
2. The server sends this ticket to the client in a NewSessionTicket message. The client stores it locally.
3. On reconnection, the client attaches the ticket to its ClientHello. The server decrypts it with its local STEK copy, recovers the resumption secret, and skips the key negotiation phase.

The critical property here is statelessness: the server stores nothing per-session. All resumption state lives inside the encrypted ticket on the client. For a distributed edge fabric where any of a hundred PoPs might field the next packet from a roaming client, this is architecturally essential—there is no shared session database to synchronize.

[ Client ]                               [ Distributed Edge Proxy ]
     |                                               |
     | ---- ClientHello (With Session Ticket) -----> |
     |                                               |  [ Decrypts ticket ]
     |                                               |  [ Using active STEK ]
     | <-- ServerHello (Resumed Session, 0/1-RTT) -- |

---

2. The Session Ticket Vulnerability: Breaking Forward Secrecy

TLS achieves Perfect Forward Secrecy (PFS) through ephemeral Diffie-Hellman key exchanges: even if an adversary later compromises a server’s long-term private key, they cannot decrypt previously captured session traffic because each session’s symmetric keys were derived from a fresh, discarded ECDHE keypair.

Session tickets undermine this guarantee at a structural level. The session ticket contains the resumption secret. The STEK encrypts the ticket. An adversary who extracts the STEK—through memory disclosure, a side-channel, or a compromised insider—can decrypt every ticket encrypted under that key and recover the underlying session secrets.

As the USENIX Security 2023 paper by Hebrok et al. puts it directly: an adversary who can compromise the STEK can passively record and decrypt TLS sessions, and may also impersonate the server.

What the Research Record Shows

The danger is not theoretical. Three distinct classes of real-world failure have been documented:

The static key trap. Many open-source load balancers and proxy implementations generate a STEK at process startup and rotate it only on restart. A server with high uptime can expose months of historical session data to a single key extraction. RFC 5077 itself recommended rotating the STEK at least every 24 hours precisely because a compromise of the key exposes only sessions from that rotation interval rather than all historical traffic.

The all-zero STEK (CVE-2020-13777). GnuTLS versions 3.6.4 through 3.6.13 contained a rotation initialization bug: the session struct is zeroed at startup, and the STEK is not actually populated until the first scheduled rotation fires—six hours later by default. During that initial window, all session tickets were encrypted with an all-zero key, meaning anyone could decrypt them with zero cryptographic effort. For TLS 1.2 connections, this allowed full passive plaintext recovery of all traffic. For TLS 1.3, it reduced to a man-in-the-middle attack against the resumed session. The bug was introduced when the project added TOTP-based rotation support; the initialization path failed to trigger an immediate key generation before issuing the first ticket.

The AWS ALB uninitialized key incident (AWS-2021-002). In April 2021, AWS disclosed that an edge case introduced in September 2020 caused a small percentage of Application Load Balancer (ALB) traffic to intermittently use an uninitialized session ticket encryption key during quiet low-traffic periods. The window of exposure lasted until April 16, 2021, when AWS deployed a full mitigation. Knowledge of the edge case would theoretically allow decryption of affected session tickets, though AWS noted that traffic traversing AWS network encryption controls remained protected.

Weak keys and repeating keystreams. The USENIX Security 2023 large-scale analysis by Hebrok, Nachtigall, Maehren, Erinola, Merget, Somorovsky, and Schwenk—the first systematic cryptographic audit of session ticket implementations at internet scale—found that vulnerable servers used weak keys or repeating keystreams in their tickets, enabling session ticket decryption. Among the most significant findings: a widespread implementation flaw within the Amazon AWS ecosystem that allowed passive traffic decryption for at least 1.9% of the Tranco Top 100k servers. The paper won a Distinguished Artifact Award at USENIX Security 2023.

Virtual host session ticket confusion (USENIX Security 2025). A follow-on paper from the same research group—”STEK Sharing is Not Caring: Bypassing TLS Authentication in Web Servers using Session Tickets” (Hebrok et al., 2025)—demonstrated that sharing a STEK across virtual hosts on the same IP and port allows session tickets from one virtual host to be reused against another, bypassing both client and server certificate authentication. Their large-scale scans found all four analyzed open-source implementations—Apache (CVE-2025-23048), nginx (CVE-2025-23419), (Open)LiteSpeed, and Caddy—vulnerable to client authentication bypasses, and identified six clusters of vulnerable CDN providers including Fastly susceptible to server authentication bypasses. Fastly fixed the issue by binding tickets to the issuing certificate; Cloudflare, as an initial mitigation, disabled session tickets when client authentication is active.

CVE-2025-23419 (nginx / F5 NGINX Plus, 2025). When multiple nginx server blocks share the same IP address and port and the default server block uses TLS session tickets or the SSL session cache, a client that authenticates legitimately against the default server can resume that session against a different server block without re-presenting its certificate. The vulnerability affects nginx 1.11.4 and later built with OpenSSL when TLSv1.3 and session resumption are enabled, and was patched in nginx 1.26.3 and 1.27.4.

---

3. The Synchronization Conundrum in Distributed Edge Proxies

Securing a single server with a local STEK rotation script is a solved problem. Handling STEK rotation across a globally distributed proxy fabric operating under Anycast routing is a fundamentally different challenge.

+---------------------------------------------------------------------+
|                        CENTRAL KEY MANAGER                          |
|         (Generates & Cryptographically Signs New STEKs)             |
+---------------------------------------------------------------------+
              |                                  |
    Secure Distribution                Secure Distribution
              v                                  v
  +-----------------------+         +-----------------------+
  |    Anycast PoP A      |         |    Anycast PoP B      |
  |  (Tokyo Edge Node)    |         |  (London Edge Node)   |
  |   - Active STEK v2   |         |   - Active STEK v2   |
  |   - Retiring STEK v1 |         |   - Retiring STEK v1 |
  +-----------------------+         +-----------------------+
              |                                  |
              +----------------------------------+
                              |
                     [ Mobile Client ]
               (Roams Tokyo → London mid-session)

In a distributed edge topology, a client may initiate a connection at a Tokyo PoP, receive a session ticket encrypted under that node’s active STEK, roam via Anycast to a London PoP, and present the same ticket. If London does not possess the exact STEK that encrypted the ticket, session resumption fails and the proxy falls back to a full 1-RTT handshake.

If this synchronization failure fires at scale during a global rotation window—every edge node rotating simultaneously—the result is a stampede of full cryptographic handshakes. CPU exhaustion at the ingress layer follows, latency spikes, and under sustained load, cascade failures across the edge fabric become possible.

The tempting operational shortcut is to configure a single static STEK across all global instances via a shared configuration file and leave it unchanged indefinitely. This is exactly the wrong tradeoff: it trades well-understood operational risk (a brief latency spike during rotation) for an open-ended confidentiality exposure that grows with every passing hour.

---

4. Engineering an Automated, Zero-Downtime STEK Rotation Loop

The solution is a multi-keyed cryptographic lifecycle that ensures every proxy node simultaneously holds multiple keys in distinct operational states: one for active encryption, one or more for graceful decryption of still-circulating older tickets, and a clean purge path that erases keys from volatile memory once their tickets have expired.

The Four Stages of the STEK Lifecycle

A well-designed rotation architecture tracks each key through four states:

Pre-staged (Next). A newly generated key that has been distributed to all global edge nodes but is not yet used to encrypt any data. This pre-distribution window—typically 5–15 minutes—absorbs network propagation delay and clock skew, ensuring every node holds the key before it becomes the active encryptor.

Active (Primary). The key currently used to encrypt all newly issued session tickets and to decrypt incoming tickets that were encrypted by it.

Retiring (Previous). A key no longer used for encryption, but retained in memory to decrypt older tickets still circulating in client browsers. Browser session tickets often have a lifespan of up to 24 hours, so the retiring stack must be deep enough to cover that window.

Purged (Expired). The key is securely overwritten in volatile memory. Once purged, any adversary holding historical ciphertext encrypted under that key loses their decryption capability—this is the cryptographic definition of forward secrecy for that time window.

Rotation Cadence

RFC 5077 recommended rotating the STEK at least every 24 hours as a minimum baseline. Production edge operators with higher security requirements commonly rotate every 1–6 hours. At hourly rotation with a 24-hour browser ticket lifetime, the proxy must maintain a stack of approximately 24 retiring keys alongside the active key.

Time Window	STEK Slot 1 (Primary)	STEK Slot 2 (Retiring)	STEK Slot 3 (Retiring)	STEK Slot 4 (Expired)
00:00 – 01:00	Key_C (Encrypt/Decrypt)	Key_B (Decrypt only)	Key_A (Decrypt only)	Key_0 (Purged from RAM)
01:00 – 02:00	Key_D (Encrypt/Decrypt)	Key_C (Decrypt only)	Key_B (Decrypt only)	Key_A (Purged from RAM)
02:00 – 03:00	Key_E (Encrypt/Decrypt)	Key_D (Decrypt only)	Key_C (Decrypt only)	Key_B (Purged from RAM)

---

5. Step-by-Step Implementation Guide

Step 1: Cryptographically Secure Key Generation

The central key coordinator must use a Cryptographically Secure Pseudorandom Number Generator (CSPRNG). For nginx’s implementation of RFC 5077, a STEK requires 48 bytes of raw entropy: 16 bytes for a unique Key Name (used by the client to identify which STEK encrypted its ticket), 16 bytes for an AES-128 encryption key, and 16 bytes for an HMAC-SHA256 authentication key.

#!/usr/bin/env bash
set -euo pipefail

# Generate a cryptographically secure 48-byte STEK for nginx
KEY_NAME=$(openssl rand -hex 16)
AES_KEY=$(openssl rand -hex 16)
HMAC_KEY=$(openssl rand -hex 16)

# Write the raw binary structure directly to volatile memory—never to disk
echo "${KEY_NAME}${AES_KEY}${HMAC_KEY}" | xxd -r -p > /dev/shm/stek_new.bin

The output lands in /dev/shm—a tmpfs-backed memory filesystem—rather than block storage. This matters: forensic extraction from deleted disk blocks is a documented attack path; keys that never touch non-volatile storage have no recovery surface after they are overwritten.

Step 2: Secure Distribution Pipeline

The central key manager—HashiCorp Vault is a common choice for its dynamic secret engine, audit logging, and access policy enforcement—generates a new STEK on a fixed cadence, bundles the current active key plus the required retiring keys into a stacked key file, and distributes it to all edge nodes over a mutually authenticated TLS (mTLS) control channel.

The distribution daemon on each edge node writes the received key material directly into a tmpfs path and never buffers it to disk. The control channel itself must be mTLS-authenticated and monitored; a compromised distribution channel is a higher-value target than a single edge node, since it touches every node in the fleet.

Step 3: Zero-Downtime Reload in nginx

nginx’s ssl_session_ticket_key directive accepts a path to a binary key file. When multiple keys are listed—or when a single file contains stacked 48-byte keys—nginx uses the first key to encrypt new tickets and attempts all subsequent keys when decrypting incoming ones.

http {
    ssl_session_tickets on;

    # Memory-backed path; never points to a persistent disk location
    ssl_session_ticket_key /dev/shm/tls_session_ticket.keys;

    server {
        listen 443 ssl;
        server_name api.example.com;

        ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
        ssl_protocols       TLSv1.2 TLSv1.3;

        # CVE-2025-23419 mitigation: disable tickets per-vhost when mTLS is active
        # ssl_session_tickets off;
    }
}

The atomic key replacement and graceful reload sequence:

# Stack the current active key first, followed by the retiring keys in age order
cat /dev/shm/stek_current.bin \
    /dev/shm/stek_previous_1.bin \
    /dev/shm/stek_previous_2.bin \
    > /dev/shm/tls_session_ticket.keys.tmp

# Atomic overwrite—mv on the same filesystem is a rename(2) syscall, which is atomic
mv /dev/shm/tls_session_ticket.keys.tmp /dev/shm/tls_session_ticket.keys

# SIGHUP triggers a graceful reload: new workers pick up the updated key file,
# old workers continue serving active connections until natural close
nginx -s reload

When nginx receives SIGHUP, the master process forks new worker processes that inherit the updated memory structure. Existing workers finish their active connections under the old key set and exit cleanly—no connections are dropped.

CVE-2025-23419 Mitigation

As the 2025 USENIX research demonstrated, sharing a STEK across nginx server blocks that serve different virtual hosts on the same IP:port allows a session ticket issued for one virtual host to be resumed against another, bypassing client certificate requirements. If your configuration uses multiple server blocks on a shared IP:port with any form of client certificate authentication, the correct mitigation is to disable session tickets on the default server or on any server block where mTLS controls access:

server {
    listen 443 ssl default_server;
    ssl_client_certificate /etc/ssl/ca.crt;
    ssl_verify_client on;

    # Disable tickets to prevent cross-vhost session confusion
    ssl_session_tickets off;
}

Nginx 1.26.3 and 1.27.4 include the upstream fix.

---

6. TLS 1.3 PSK Architecture and the 0-RTT Exception

TLS 1.3 replaces the explicit RFC 5077 session ticket structure with a unified PSK resumption model. The architectural improvements are real, but they are accompanied by one significant exception: 0-RTT early data.

psk_dhe_ke Restores Forward Secrecy for Standard Resumption

TLS 1.3 defines two PSK key exchange modes: psk_ke (pure symmetric resumption, no additional key exchange) and psk_dhe_ke (PSK plus an ephemeral Diffie-Hellman exchange). When configured with psk_dhe_ke, a resumed session still performs a fresh ECDHE exchange after ticket validation. The application data that follows is wrapped in a session key derived from both the resumption secret and the new ephemeral exchange—meaning even an adversary who extracts the STEK cannot decrypt the resumed session’s application data without also breaking the ephemeral key exchange.

Enforcing psk_dhe_ke mode in a post-quantum threat context is also directly relevant: research on harvest-now, decrypt-later attacks specifically identifies the combination of psk_dhe_ke mode and frequent STEK rotation as severing the resumption chain that passive bulk-collection adversaries rely on.

0-RTT: The Vulnerability That Remains

0-RTT allows a returning client to bundle HTTP requests directly inside its initial ClientHello, achieving zero-latency data transmission for the first round trip. This is the mechanism CDN providers market as “instant resumption.”

[ Client ]                               [ Distributed Edge Proxy ]
     |                                               |
     | -- ClientHello + 0-RTT Data (via PSK) ------> |
     |                                               |  [ Decrypts immediately ]
     |                                               |  [ Forwarded to backend ]
     |                                               |  [ ECDHE not yet complete ]

Because this early data is sent before the ECDHE exchange completes, its confidentiality rests entirely on the resumption secret inside the session ticket—the STEK-encrypted blob. An adversary holding a compromised STEK can decrypt 0-RTT data immediately and without any additional cryptographic work.

Worse, 0-RTT data is inherently vulnerable to replay attacks. The protocol itself admits this: RFC 8446 Section 8 explicitly places the burden of replay protection for 0-RTT data on application developers rather than on the TLS layer. An attacker can intercept a legitimate 0-RTT packet—a financial transfer, a state-changing API call, an authentication request—and replay it against one or more edge PoPs. Because the stateless proxy decrypts the ticket and processes the embedded request without per-request state, duplicate execution is the default unless the application explicitly prevents it.

In practice this matters. Replaying a POST /api/transfers request results in duplicate transaction execution. Replaying an order submission results in duplicate charges. The CertGuard analysis from March 2026 documented a case where an attacker replaying 0-RTT webhooks against multiple CDN PoPs triggered duplicate payment processor charges; the anomaly was caught only because the downstream processor flagged duplicate transaction IDs.

---

7. Anti-Replay Mitigations for 0-RTT Environments

Defensive posture for 0-RTT requires controls at multiple layers:

Restrict 0-RTT to idempotent HTTP methods. The correct baseline is to block 0-RTT processing at the proxy for any method that carries side effects. Only GET, HEAD, and OPTIONS are safe candidates for 0-RTT delivery—replaying them produces the same result. POST, PUT, PATCH, and DELETE must be rejected from 0-RTT data and forced to wait for the completed 1-RTT handshake.

Ticket age validation. TLS 1.3 includes an obfuscated ticket age extension in the ClientHello. The proxy evaluates whether the claimed ticket age falls within an acceptable delta relative to the server’s current clock. Requests where the delta exceeds the acceptable window—indicating a replayed or stale packet—should be rejected or forced through a full handshake. This provides approximate protection but is not a cryptographic guarantee.

Application-layer idempotency keys. For any endpoint that must accept non-GET traffic and where 0-RTT cannot be fully disabled, the application should require a per-request idempotency key in the request payload or header. The backend checks this key against a short-lived deduplication store before executing. This is the most reliable defense because it operates independently of TLS configuration.

Puncturable Pseudorandom Functions (PPRFs). Academic research by Aviram, Gellert, and Jager (published in the Journal of Cryptology, 2021) proposes a server-side mechanism where the STEK itself is “punctured” after each ticket is consumed. The server derives a new key that can decrypt any ticket except the one just used, then discards the original. This makes each ticket decryptable exactly once, eliminating replay at the cryptographic layer. The approach provides forward secrecy and replay resistance simultaneously, though the naive public-key puncturable encryption construction produces impractically long key material; the PPRF-based construction in the paper resolves this with practical key sizes.

Disable 0-RTT for sensitive endpoints. When the above controls are not feasible, the simplest correct posture is to disable 0-RTT entirely for endpoints where replay would be consequential. Most CDN and proxy platforms allow per-route 0-RTT configuration. The latency cost of a single additional round trip on reconnect is measurable but bounded; the cost of undetected replay-driven fraud is not.

---

8. Observability, Auditing, and Telemetry

A STEK rotation system without monitoring is a security control that can fail silently for extended periods. Cryptographic anomalies do not trigger traditional uptime alarms—a proxy serving encrypted garbage looks identical to a healthy proxy from the outside.

Critical Telemetry Metrics

Infrastructure teams should expose and alert on these specific TLS metrics at the edge ingress layer:

tls.resumption.ticket_received — gross volume of clients attempting stateless session resumption.

tls.resumption.success — handshakes successfully negotiated using a current or retiring valid STEK.

tls.resumption.fail.key_not_found — client presented a ticket, but no STEK in the local stack matched the key name field. Sustained spikes here indicate a synchronization lag in the global STEK distribution pipeline—the symptom of the “cache miss stampede” problem described in Section 3.

tls.resumption.fail.decryption_error — key name matched, but HMAC verification or structural decryption failed. A baseline of occasional failures is normal (bit-flipped tickets, corrupted client storage); a sustained uptick is a primary indicator of active tampering, fuzzing by a threat actor, or key corruption in the local stack.

Automated Key Integrity Checks

The rotation daemon should execute continuous health checks against the live key material in volatile memory:

#!/usr/bin/env bash
KEY_FILE="/dev/shm/tls_session_ticket.keys"
EXPECTED_UNIT=48  # bytes per STEK

# Verify the file exists and is non-zero
if [[ ! -s "$KEY_FILE" ]]; then
    echo "CRITICAL: STEK key file is missing or empty" >&2
    exit 2
fi

FILE_SIZE=$(stat -c%s "$KEY_FILE")

# Verify size is an exact multiple of 48 bytes
if (( FILE_SIZE % EXPECTED_UNIT != 0 )); then
    echo "CRITICAL: STEK key file size ${FILE_SIZE} is not a multiple of ${EXPECTED_UNIT}" >&2
    exit 2
fi

# Verify entropy is not suspiciously low (null-byte or all-zero key file)
NULL_BYTES=$(xxd -p "$KEY_FILE" | tr -d '\n' | grep -o '00' | wc -l)
TOTAL_BYTES=$(( FILE_SIZE * 2 ))  # hex chars
NULL_RATIO=$(echo "scale=4; $NULL_BYTES / $TOTAL_BYTES" | bc)

if (( $(echo "$NULL_RATIO > 0.10" | bc -l) )); then
    echo "CRITICAL: STEK key file has suspiciously high null-byte ratio: ${NULL_RATIO}" >&2
    exit 2
fi

echo "OK: STEK key file is ${FILE_SIZE} bytes, ${FILE_SIZE / EXPECTED_UNIT} keys, entropy check passed"

The null-byte ratio check directly targets the failure mode that produced CVE-2020-13777 and the AWS-2021-002 incident: a rotation process that silently overwrites the live key file with zeroed or uninitialized bytes.

Virtual Host Isolation Audit

Given the 2025 research disclosures, any nginx or Apache deployment using multiple server blocks on a shared IP:port should also audit session ticket scope:

# Check for mixed mTLS + session ticket configurations on shared listeners
nginx -T 2>/dev/null | awk '
    /server {/           { in_server=1; mTLS=0; tickets=1; ip="" }
    /listen/             { ip=$2 }
    /ssl_verify_client on/ { mTLS=1 }
    /ssl_session_tickets off/ { tickets=0 }
    /^[[:space:]]*}/    {
        if (in_server && mTLS && tickets)
            print "WARNING: mTLS+session tickets on " ip " — CVE-2025-23419 exposure"
        in_server=0
    }
'

---

9. Conclusion

The STEK is one of the highest-value symmetric keys in a distributed TLS deployment. It does not protect a single session—it protects every session encrypted under it, including all sessions that were recorded before the key was extracted and that can be decrypted retrospectively. A static, unrotated STEK effectively converts your edge proxy fleet into a passive decryption oracle for any adversary with enough patience and a packet capture device.

The 2020 GnuTLS zero-key incident, the 2021 AWS ALB uninitialized-key disclosure, the 2023 USENIX large-scale scan findings (including the AWS ecosystem flaw covering 1.9% of the Tranco Top 100k), and the 2025 virtual-host session ticket confusion vulnerabilities across Apache, nginx, (Open)LiteSpeed, Caddy, and Fastly collectively establish that STEK mismanagement is not an edge case. It is the predictable result of leaving key lifecycle management to default configurations.

The practical engineering path is well-defined: memory-only key storage, centralized CSPRNG-based generation, pre-staged distribution with a propagation window, a multi-slot retiring stack sized to browser ticket lifetimes, atomic reload signaling, and continuous entropy monitoring. Add psk_dhe_ke enforcement for TLS 1.3 to restore forward secrecy for standard resumed sessions, restrict 0-RTT to idempotent methods or disable it on sensitive routes, isolate STEK scope per virtual host wherever mTLS enforces access control, and instrument your resumption failure counters for real-time alerting.

The rotation window—the window during which a STEK is active and a future compromise of it could unlock historical traffic—is the quantifiable exposure that automated rotation controls. Every hour a key rotates without incident is an hour of traffic that will remain confidential regardless of what happens to the edge infrastructure afterward.

---

References

Aviram, N., Gellert, K., & Jager, T. (2021). Session Resumption Protocols and Efficient Forward Security for TLS 1.3 0-RTT. Journal of Cryptology, 34(3). https://doi.org/10.1007/s00145-021-09385-0

AWS Security. (2021, April 26). Resolved: Application Load Balancer Session Ticket Issue (AWS-2021-002). https://aws.amazon.com/security/security-bulletins/AWS-2021-002

Hebrok, S., Nachtigall, S., Maehren, M., Erinola, N., Merget, R., Somorovsky, J., & Schwenk, J. (2023). We Really Need to Talk About Session Tickets: A Large-Scale Analysis of Cryptographic Dangers with TLS Session Tickets. 32nd USENIX Security Symposium, 4877–4894. https://www.usenix.org/conference/usenixsecurity23/presentation/hebrok

Hebrok, S., Storm, T. L., Cramer, F. M., Radoy, M., & Somorovsky, J. (2025). STEK Sharing is Not Caring: Bypassing TLS Authentication in Web Servers using Session Tickets. 34th USENIX Security Symposium. https://www.usenix.org/conference/usenixsecurity25/presentation/hebrok

Klute, F. (2020). CVE-2020-13777: GnuTLS uses an all-zero STEK in the first key rotation interval. https://gitlab.com/gnutls/gnutls/-/issues/1011

NVD. (2025). CVE-2025-23419: nginx client certificate authentication bypass via TLS session resumption. https://nvd.nist.gov/vuln/detail/CVE-2025-23419

NVD. (2025). CVE-2025-23048: Apache httpd client authentication bypass via TLS session resumption. https://nvd.nist.gov/vuln/detail/CVE-2025-23048

Rescorla, E. (2018). The Transport Layer Security (TLS) Protocol Version 1.3 (RFC 8446). IETF. https://www.rfc-editor.org/rfc/rfc8446