Two TLS Entry Paths, One Ambiguous Session
In the Opossum attack, the decisive move is not breaking TLS but changing which application state leads into a valid TLS session. This chapter traces how a pure man-in-the-middle delays and redirects the connection so that one peer believes it used implicit TLS while the other believes it upgraded an existing application conversation. The practical result is a way to identify the first unexpected message and test whether another synchronous protocol has the same weakness.
The distinction is easiest to see if we treat a connection as two linked state machines. The TLS state machine moves from a handshake into protected records. The application state machine decides what those records contain and whose turn it is to speak. The Opossum attack succeeds when the first machine reaches the expected encrypted state while the second machine reaches a different point in the conversation.
The attacker changes the entry point, not the cipher
Assume a client intends to use an implicit-TLS endpoint. The client’s first bytes are a TLS ClientHello; there is no application greeting or plaintext request before it. The server at the intended service may be perfectly capable of authenticating the client and completing a current TLS handshake. Nothing in that handshake, however, requires the server to know whether the bytes arrived directly from the expected implicit endpoint or were forwarded by an intermediary that first negotiated an upgrade on another endpoint.
The Opossum attacker operates at the TCP level. They can read and manipulate the traffic that travels between the client and server, buffer a message instead of forwarding it immediately, and translate between the implicit and opportunistic service ports. They cannot break the cryptographic primitives, calculate a valid substitute for a protected record, or change the handshake transcript without being detected. The peers can therefore behave according to their specifications, and the TLS handshake can still finish normally.
That capability is enough because the handshake authenticates a narrower object than the application may need. TLS authenticates the cryptographic peer according to the identity information used by the connection and protects the records that follow. It does not inherently authenticate the client’s intended TCP port, the precise application origin, or the fact that the application reached TLS through a particular plaintext upgrade exchange. The paper relates this gap to ALPACA-style protocol confusion: a certificate can be valid for more than one service, while the TLS layer does not automatically bind the session to the application endpoint the client meant to reach.
A natural response is to rely on ALPN, the TLS extension through which a client offers application protocols and a server selects one. Strict ALPN and server-name checking can reject a connection when the peers disagree about the named protocol. Opossum addresses a subtler case. The implicit and opportunistic variants can use the same application protocol name and the same ALPN identifier. Their difference is not the label but the state inherited from before the handshake. A server can therefore select the apparently correct protocol while still expecting a different first application message.
The attacker’s role is consequently closer to joining two compatible-looking conversations than to impersonating either endpoint. They arrange the join before the encrypted phase, then forward the cryptographic exchange. The server and client share keys with each other, but they do not share the same account of how the application arrived at those keys.
The message trace shows the important ownership boundary. The attacker controls when the client’s ClientHello reaches the server and which service endpoint receives the initial upgrade request. They do not control the contents of the later TLS records. Once the handshake is complete, the attacker can still control forwarding order between the two unidirectional protected channels, but they cannot rewrite the records as they do so.
In operational terms, the two endpoints reach different post-handshake permissions. The implicit client has completed the setup needed to send an application request; it is waiting for no application response. The opportunistic server has completed an upgrade that began with a request from the other side; it may have a response ready to send before it receives a new command. TLS’s Finished checks can confirm that the handshake messages were not altered, but they do not add a transaction number to the first application record. Nothing in the protected stream identifies which side’s account of the pre-handshake conversation should control the next turn.
This also explains why client authentication does not automatically close the gap. Authenticating the client can establish who is using the channel, but it does not tell the server whether that client intended the implicit or opportunistic invocation, nor does it force the two sides to agree on who speaks first. Likewise, forwarding the unmodified handshake preserves the cryptographic relationship while hiding the attacker’s earlier choice of endpoint. The weakness is therefore in the binding between a valid channel and the application lifecycle that the channel is supposed to continue.
Two flows produce one shifted stream
The paper names the two possible directions according to the order in which the client and server invoke TLS. The direction determines which side retains the wrong expectation, but both cases create a disagreement about the first application message after encryption.
Implicit to opportunistic
In the I2O case, the client starts as if it were connecting to an implicit-TLS service. Its ClientHello is the complete beginning of the connection from the client’s point of view. The attacker delays that message and opens a separate TCP connection to the server’s opportunistic endpoint. On that second connection, the attacker sends the plaintext command or request that asks the server to upgrade to TLS. The server accepts the request and enters its TLS-handshake state.
Only then does the attacker forward the delayed ClientHello and the rest of the handshake between the legitimate client and server. From TLS’s perspective, this is a normal exchange: the client offers parameters, the server selects them and presents its identity, and both sides verify the handshake before sending application data.
The application states are not normal in the same way. The implicit client has sent no application request yet, so it believes it should speak first. The opportunistic server has already processed an upgrade request, so it may believe its first encrypted message should be the response associated with that request. In the paper’s abstract trace, the client’s first legitimate request is REQ1, while the server’s first message from its retained state is MSG1. The attacker can forward MSG1 to the client as though it were the response to REQ1.
The consequence does not require the client to accept an obviously malformed TLS record. MSG1 is a valid application response from the authenticated server on the protected connection. The error is the assignment of that response to the wrong request. If the client continues sending requests, it can interpret the next server response as belonging to the next request, and the shift can persist. In a protocol whose messages are defined by their position rather than by independent transaction identifiers, each later interpretation can remain syntactically plausible while being semantically wrong.
HTTP is the clearest I2O case because the attacker chooses the plaintext upgrade request. They can ask for a resource or use a method and headers that shape the server’s response. The client’s first request then becomes the slot into which that chosen response is delivered. The cryptographic tunnel has not been pierced; it has been made to carry a response selected for a different application request. The following chapter examines why that control makes HTTP more consequential than a protocol that sends only a fixed greeting.
Opportunistic to implicit
The O2I case reverses the entry assumptions. Here the client begins on an ordinary plaintext service endpoint and expects an in-band negotiation. Before the upgrade, the attacker can act as the server for the purpose of sending the banner or other protocol-compliant messages needed to make the client request TLS. Once the client begins its TLS handshake, the attacker forwards it toward an implicit-TLS server.
The implicit server has a different starting state. It expects TLS to have been the first event on the connection, and after the handshake it may send the greeting that normally opens an implicit session. The opportunistic client, by contrast, has already completed what it considers the upgrade and expects to send its first command. The server’s greeting, MSG1, can therefore arrive where the client expects RESP1, the response to that first command.
This direction applies to the pattern described for FTP, SMTP, POP3, LMTP, and NNTP. An implicit server’s banner can be mistaken for a response to the client’s first post-upgrade command. Whether the client rejects the unexpected status or continues is application-specific, so the protocol-level condition does not automatically imply a complete exploit. It does show that the supposedly protected channel permits an application message from one entry variant to appear in the other variant’s response position.
The O2I scenario also clarifies why the attack is not equivalent to simply forwarding a client to the wrong port. The attacker must preserve enough of the opportunistic dialogue to get the client into TLS, then forward the resulting handshake to a peer that assumes the dialogue never happened. The mismatch is a lifecycle error: the two endpoints agree that the handshake is over but disagree about which pre-handshake events count as part of the application conversation.
The first unexpected message is also a useful failure boundary. A client may reject a greeting where a response code is expected, close the connection, or stop waiting when the two sides’ simultaneous messages do not fit its parser. In that case the attack produces an error or a hang rather than a useful shifted conversation. The paper notes that the attacker can keep delaying responses until one peer stops responding, but indefinite delay is not the same as a successful exploit. The application must continue the connection, accept the message in the relevant position, and expose some later operation that benefits from the shift. This is why the protocol diagrams establish susceptibility, while product behavior determines whether an attacker can build a practical consequence.
Why delaying one response matters
A static mismatch might produce only an immediate protocol error. Opossum can be more flexible because TLS protects client-to-server and server-to-client traffic as separate channels. The attacker can hold back a server response while waiting for the client to send another request. In the paper’s I2O description, they may delay RESP1 until they have received and blocked REQ2; the client then receives the server’s unexpected MSG1 as the apparent answer to REQ1. If the connection remains alive, the delayed RESP1 can be interpreted as the answer to REQ2, and the same offset can continue.
This timing does not give the attacker arbitrary control over every byte. The attacker cannot send an incomplete message and cannot turn a protected record into one of their own. The paper compares the result with TLS renegotiation prefix attacks and notes that Opossum is weaker: the injected prefix must be a complete request in the HTTP case. But a complete, valid request can still be enough to change which resource, session state, or application action the client observes.
The boundary conditions can now be stated as a short diagnostic test. First, the service must expose both implicit and opportunistic TLS, either directly or because a transparent TLS proxy supplies one of the variants. Second, the two variants must differ in their application behavior after the handshake, especially in which side sends the first application data. Third, the protocol’s response semantics must make order or message position meaningful. Remove any one of these conditions and the classic Opossum desynchronization may not follow.
That test explains both the breadth and the limits of the finding. A protocol that supports only opportunistic TLS has no implicit entry state for the attacker to confuse with it, unless infrastructure adds one. A protocol that behaves identically after either kind of handshake may have two ports but no relevant state split. A protocol with client-selected response tags may tolerate an unexpected banner without shifting every subsequent response. Conversely, a seemingly minor difference in first-message ownership can be enough to create an authentication gap even when the protocol name, certificate, and TLS transcript all look correct.
The next question is what happens when the attacker can control more than the timing of that first message. HTTP/1.1 supplies exactly that opportunity: its older Upgrade mechanism lets the attacker seed the opportunistic side with a chosen request, making the wrong response not merely unexpected but useful.