When HTTPS Receives the Wrong Response
The Opossum attack becomes most concrete in HTTP/1.1, where an old in-band TLS upgrade lets an attacker choose the request that seeds the server’s encrypted state. This chapter follows that HTTP flow and asks what a browser can do with a response that is authentic, well-formed, and intended for a different request. The answer supports a careful judgment: Opossum does not give an attacker arbitrary control over HTTPS, but it can turn application-layer desynchronization into resource substitution, session-state changes, reflected-XSS amplification, and—under Apache-specific behavior—a request-body path that exposes cookies.
HTTP is a particularly revealing case because the application protocol gives the attacker more than a fixed greeting. A request names a resource, method, headers, and sometimes a body. If the server processes the attacker’s request while the browser waits for the answer to its own request, the resulting response can be useful rather than merely confusing.
The upgrade is a request, not just a switch
HTTP/1.1 was designed to carry requests and responses as plaintext. RFC 2817 defined a way to ask an existing HTTP connection to move into TLS without opening a new connection. The client sends an ordinary HTTP request with an Upgrade: TLS/... header. The server can accept by returning 101 Switching Protocols with the corresponding upgrade information. The client then starts the TLS handshake on that same TCP connection, and the requested resource is expected to arrive through the newly protected channel.
That sequence embeds application meaning on both sides of the handshake. Before TLS begins, the server has already received a request and made a decision about whether to switch protocols. After TLS begins, it may be ready to send the response associated with that request. The client, however, can treat the connection differently: once it has established an implicit-style TLS channel, it may believe that no HTTP request has yet been sent and that its next message should be a fresh request. The two sides are encrypted together but are not at the same point in HTTP’s request/response lifecycle.
Modern web browsers did not widely adopt HTTP-to-TLS Upgrade. That fact limits where the feature appears, but it does not remove the Opossum condition. A browser can use ordinary implicit HTTPS, while an HTTP server still accepts the older opportunistic upgrade on another port. The browser does not need to know how to request an upgrade. The man-in-the-middle supplies that alternate entry path and forwards the browser’s TLS handshake to the server that accepted it.
The HTTP version of the attack therefore has three distinct participants in the application story. The browser believes it is speaking first on an implicit HTTPS connection. The attacker creates a plaintext HTTP connection to the server and chooses the upgrade request on that connection. The server believes it has accepted an HTTP request and upgraded the conversation that contains it. Once the attacker joins the connections at the TLS layer, the browser and server share a valid encrypted channel while assigning different meanings to its first HTTP messages.
The request /dog and the request /cat are not special protocol values; they make the state shift visible. The attacker can choose a complete request for one resource, delay the browser’s ClientHello, and then forward the handshake without changing it. After the handshake, the browser sends its intended /cat request. The server responds to the request that began the opportunistic side, /dog, and the browser receives that response in the position where it expects the /cat response.
The response is not forged. It is protected by the TLS keys established between the browser and server, and the server may have generated it exactly as it would for any legitimate /dog request. The failure is the association between a response and a request. HTTP/1.1 normally relies on the order of messages on a persistent connection to maintain that association. Once the first pair is shifted, later pairs can remain shifted as long as the connection survives and both implementations continue processing the stream.
This is also why the attack does not depend on a browser implementing the opportunistic feature. The browser contributes the implicit-TLS behavior and its ordinary request; the server contributes the upgrade-capable behavior; the attacker supplies the missing bridge. The server need not knowingly accept a malformed TLS conversation, and the browser need not accept plaintext after it expects encryption. Each endpoint can follow its local rules while the combined flow violates the shared application assumption those rules were supposed to create.
From wrong resource to wrong state
Once the response position is wrong, the consequences depend on what the attacker’s chosen request causes the server to return and how the browser processes that return. The paper presents four HTTP exploit directions. They form an impact ladder, not a promise that every vulnerable deployment supports every outcome: resource confusion is the basic effect, while session fixation, reflected-XSS amplification, and cookie exposure require additional application or implementation conditions.
Resource confusion
The simplest consequence is a substitution of one resource for another. If the browser asks for /cat but receives the server’s response to the attacker’s /dog request, it may render or use the wrong content under the trusted connection. The same pattern can replace an image, an executable download, or a JavaScript source file with another object served by the same application.
That last case matters because browsers and applications often treat a script response as part of the trusted site’s behavior. Replacing a security-sensitive library could downgrade the code actually executed by the page or prevent a protection such as DOMPurify from operating. The Opossum mechanism does not manufacture arbitrary bytes or make every substitute executable. The attacker needs a useful response available from the relevant server, and the browser must accept it at the position created by the desynchronization. The practical impact is therefore application-dependent, but the trust boundary has still shifted: the browser is no longer sure that the response it authenticated is the response to the request it issued.
This is different from a normal network attacker editing an HTTPS response. TLS prevents that direct modification. The attacker instead exploits an ambiguity that exists before the response is interpreted. The server’s message remains intact; the browser’s request/response bookkeeping is what changes.
Session fixation and anti-CSRF state
A chosen request can do more than retrieve static content. It can invoke a login or another operation that causes the server to set a cookie. If the attacker submits credentials for an account they control in the request that seeds the opportunistic side, the browser may receive the resulting session cookie as though it belonged to its own request. The user is then logged into the attacker’s account rather than their own. This is session fixation: the attacker arranges the session state the victim will use; it is not the same as stealing an already authenticated victim session.
The same response confusion can affect a cookie used for cross-site request forgery protection. The paper reports a proof of concept against CUPS, a printing service with an administrative interface, that forces a chosen anti-CSRF cookie into the client. Later requests from that client can then be paired with the attacker’s known token, making CSRF attacks against the administrative interface possible when the application’s other conditions permit them.
These examples show why response pairing is part of the security model even when the TLS certificate and cookie flags appear correct. A browser can receive a Set-Cookie header from the genuine server over a protected connection and still store the wrong session state if the response was generated for a request the browser never made. The attack depends on the application changing state in response to the attacker-controlled request and on the client accepting the result as a same-origin response. It is not a universal bypass of browser cookie policy.
Reflected XSS as exploit composition
The Opossum attack can also amplify a reflected cross-site scripting condition. In a conventional reflected-XSS scenario, a user may need to follow a specially crafted link that produces a GET request containing the payload. The attacker may have no way to choose the HTTP method or add the exact header that triggers the vulnerable reflection. Opossum changes the shape of the request that the server sees: the attacker controls the method, resource, and headers of the plaintext upgrade request, and the resulting response can be delivered to the browser in the slot of its request.
The underlying reflection remains necessary. Opossum does not create a script sink in a server that safely encodes every response, nor does it defeat the browser’s same-origin policy by itself. It can make a previously awkward reflected self-XSS or header-dependent condition reachable in a normal browser context. The paper’s range-header proof of concept illustrates the point: a server that supports byte ranges can be asked to return a part of a response containing a commented-out script tag, potentially turning the selected response into executable markup in the browser’s context.
There is an important browser-side limit. Multiple ranges may give the attacker more control over response pieces, but Apache’s multipart range format is generally treated by modern browsers as a download rather than rendered page content. That constraint does not erase the exploit direction; it shows why the result must be evaluated as a chain of conditions rather than described as arbitrary response construction.
Apache’s request-body boundary
The strongest HTTP result in the paper comes from a product-specific difference in how Apache handles the body of the upgrade request. The RFC 2817 flow expects the complete initial request, including its body, to be sent in plaintext before the protocol switches. The paper reports that Apache instead expects only the headers before the switch and expects the body to arrive after the TLS handshake, on the assumption that the client already knows the upgrade will succeed.
That assumption interacts badly with Opossum. From the browser’s perspective, the first post-handshake bytes can be the body of its legitimate request. From Apache’s perspective, those bytes fill the body of the attacker’s earlier upgrade request. After Apache consumes the number of bytes declared by that attacker-controlled request, the remaining bytes can be parsed as a new HTTP request. The problem has moved from a shifted response pair to shifted request boundaries, which is why the paper compares the effect with request smuggling.
The proof of concept uses a Man-in-the-Browser setting in addition to the TCP-level man-in-the-middle: an attacker-controlled site submits a form to the target over HTTPS, while the intermediary performs the Opossum setup. The attacker can control the structure and declared length of the upgrade request, so the victim’s request body becomes data inside the attacker’s server-side request. A later same-origin subresource request can then be parsed as another request or as data for an attacker-readable feature, such as a comment submission.
The cookie consequence follows from connection reuse. The paper reports that Chrome and Firefox reused the desynchronized connection for subresource requests triggered by the first response. A same-origin request for something as ordinary as a favicon can carry the browser’s cookies, including cookies marked HttpOnly and Secure. Those flags prevent JavaScript from reading the cookie and prevent it from being sent over an insecure connection; they do not stop the browser from sending the cookie on a same-origin HTTPS request. If Apache has been made to treat that request as POST data to an application endpoint that the attacker can read, the application—not JavaScript—becomes the channel through which the data is disclosed.
The proof of concept required additional conditions, including padding so the first browser request occupied a complete TLS record and record-level delaying so Apache could answer before the connection was reused. Those details matter because they locate the result correctly. This is not a claim that every Opossum-vulnerable HTTP server leaks cookies. It is a demonstration that an implementation’s decision about where an upgrade request ends can amplify the general state mismatch into a request-body desynchronization with a much more serious outcome. The paper tested CUPS, Icecast, and Cyrus IMAP as well and observed different handling of upgrade requests with content lengths; their behavior cannot be assumed to match Apache’s.
The HTTP case therefore has a clear hierarchy. At the protocol level, Opossum can make the response to a chosen request appear to answer another request. At the application level, that can alter content or session state when the application exposes the right operations. At the implementation level, a nonstandard body transition can break request boundaries and expose data that the browser sends later. Treating these as one undifferentiated “HTTPS compromise” would hide the prerequisites that determine actual risk.
The more general lesson is sharper than any single exploit. HTTPS protects the response bytes it carries, but it does not repair a disagreement about which HTTP request those bytes answer. HTTP’s unusual feature is that the attacker can choose the request on the opportunistic side, so the wrong response can be selected for a purpose. Other protocols may have the same mixed-mode state error while offering only a fixed banner or a less useful first message. The next assessment is therefore not whether a protocol uses opportunistic TLS in the abstract, but whether its first-message mismatch gives an attacker enough control to produce a meaningful application consequence.