Opossum Attack: TLS Application Desynchronization

Overview

The Opossum Attack exposes a gap between TLS record integrity and peer authentication and application-conversation integrity: implicit and opportunistic TLS can establish the same encrypted channel while leaving different expectations about who speaks first. The series traces the mixed-mode attack, explains how HTTP/1.1 can turn response confusion into conditional resource substitution, session fixation, reflected-XSS amplification, and Apache-specific request-body effects, and compares email, FTP, IMAP, and boundary cases. It separates protocol susceptibility, proof-of-concept behavior, product-specific impact, and scan-based exposure. It then evaluates removing opportunistic TLS, binding mode through enforced identity, and why SMTP REQUIRETLS solves a different downgrade-policy problem.

Learning outcomes

A successful TLS handshake authenticates the channel, not necessarily the application state it continues.
Opossum requires dual TLS entry paths, different post-handshake behavior, and meaningful message ordering.
HTTP/1.1 offers the strongest demonstrated impact because the attacker can choose the upgrade request; effects remain conditional.
Removing an obsolete upgrade path is broadest; enforced mode identity can preserve compatibility, while REQUIRETLS addresses a different SMTP policy.

Keywords

Opossum AttackTLSDesynchronizationSTARTTLSHTTP/1.1ALPNSMTPIMAPREQUIRETLS

Chapters

Opossum Attack: Wrong Application State

How implicit and opportunistic TLS diverge after the handshake

9 min · How implicit and opportunistic TLS diverge after the handshake

9 min

Opossum Attack: Two TLS Entry Paths

How timing shifts the first encrypted message

11 min · How timing shifts the first encrypted message

11 min

Opossum Attack: HTTP/1.1 Response Confusion

How HTTP/1.1 turns shifted responses into conditional impact

14 min · How HTTP/1.1 turns shifted responses into conditional impact

14 min

Opossum Attack: Email, FTP, and Protocol Limits

How banners, tags, and scans change the evidence

13 min · How banners, tags, and scans change the evidence

13 min

Opossum Attack: Fixing the Upgrade Boundary

When to remove opportunistic TLS or bind its mode

13 min · When to remove opportunistic TLS or bind its mode

13 min

Opossum Attack: TLS and Application Integrity

How to test who speaks next after TLS

14 min · How to test who speaks next after TLS

14 min

Preview every chapter · Unlock full text, audio, and video from chapter 4

Plans

Ch.1-3 FreeCh.4-6 Premium

FAQ

What does the Opossum Attack exploit?

The Opossum Attack exploits a mismatch between implicit and opportunistic TLS entry states, not a failure to encrypt or authenticate TLS records.

When is a service susceptible to the Opossum Attack?

A service is susceptible when it exposes both entry paths, leaves different post-handshake states, and relies on message order or attacker-controlled content; infrastructure can add the second path.

Why is HTTP/1.1 especially affected by the Opossum Attack?

HTTP/1.1 is especially useful because the attacker can choose the upgrade request and shape a response, enabling conditional resource, session, XSS, or Apache-specific request-body effects.

Does SMTP REQUIRETLS prevent the Opossum Attack?

No. SMTP REQUIRETLS prevents required messages from being sent when TLS negotiation or authentication fails, but it does not authenticate whether an encrypted session followed implicit or opportunistic application state.