Robert Merget (TII), Nurullah Erinola (RUB), Marcel Maehren (RUB), Lukas Knittel (RUB),
Sven Hebrok (UPB), Marcus Brinkmann (RUB), Juraj Somorovsky (UPB), Jörg Schwenk (RUB)
What is Opossum?
Opossum is a cross-protocol application layer desynchronization attack that affects TLS-based application protocols that rely on both opportunistic and implicit TLS. Among the affected protocols are HTTP, FTP, POP3, SMTP, LMTP and NNTP.
Opossum allows attackers to break the integrity of secure TLS channels by injecting unexpected messages, causing desynchronization between clients and servers. The attack requires a man-in-the-middle position and targets services that support both implicit TLS (dedicated port) and opportunistic TLS (upgrade mechanism) simultaneously.
Attack Overview
The Opossum attack exploits issues in the authentication mechanism of TLS (identified in the ALPACA attack) to desynchronize a client and a server, even if all current ALPACA countermeasures are in place. To do this, Opossum attacks small differences on the application layer between implicit TLS (where TLS is established immediately) and opportunistic TLS (where connections start in plaintext and upgrade to TLS). If a server supports both methods for a given protocol, when a client attempts to connect using one method, an attacker can redirect the connection to use the other method, creating a mismatch in protocol expectations between client and server.
In the attack, a man-in-the-middle attacker intercepts a client's TLS connection intended for an implicit TLS connection (e.g., HTTPS on port 443). The attacker establishes their own plaintext connection to the server's opportunistic TLS port (e.g., HTTP on port 80), sends a malicious request with TLS upgrade headers, then forwards the client's connection to the server as if it were part of its own connection on port 80. After the TLS handshake completes, both parties send messages simultaneously - creating a desynchronization where the client receives the wrong response to their request. The attacker can now delay the response from the server to the client, such that it appears to the client as if the server sent the application data message in response to its request. In the example in Figure 1, the attack causes the client to receive the answer "dog", even though it requested the resource "cat". This desynchronization persists for all subsequent requests in the connection.
Frequently Asked Questions
I am an admin, should I drop everything and check if I am affected?
If you know that you are using RFC 2817 you should probably check. Otherwise, you can probably take your time. While the attack is very powerful for HTTP(S), the attack scenario is rarely present as the HTTP-to-TLS-Upgrade mechanism is rarely supported. For non-HTTP protocols, the issue is (at the moment) more of a theoretical nature as we cannot show a plausible exploit. However, we would like to stress that attacks will only get better, and therefore still recommend to migrate to implicit TLS variants where possible.
What can the attackers gain?
In HTTPS contexts, we identified several attack classes:
- ▸ Resource Confusion - Serving wrong content to users
- ▸ Session Fixation - Forcing users into the attacker's session
- ▸ Reflected XSS Escalation - Upgrading self-XSS to full XSS attacks
- ▸ Implementation-Specific Issues - Cookie leakage and other vulnerabilities
For other protocols, the attack breaks channel integrity assumptions similar to the ALPACA attack, meaning that from the client's point of view, the server will answer with an application message that the server would not have sent when no attacker was there i.e., the server answers with a banner message to the first transmitted client request after the TLS connection instead of the usual response to the request, which desynchronizes the connection.
What are the attack prerequisites?
The attack requires:
- ▸ A server that supports both implicit TLS (e.g., HTTPS on port 443) and opportunistic TLS (e.g., HTTP with TLS upgrade on port 80)
- ▸ An attacker with a man-in-the-middle position between client and server
- ▸ A (synchronous) protocol where there is a difference between the opportunistic and implicit TLS variant after the TLS handshake. To the best of our knowledge, this means that HTTP, FTP, POP3, SMTP, LMTP and NNTP are affected.
So how practical is the attack?
For HTTP(S), the attack is very practical and reliable if the requirements for the attack are met. According to our studies, this is rarely the case for HTTP(S). For other protocols, the scenario is much more common, but we cannot present a practical exploit, as we did not find a way to abuse Opossum to achieve something a real attacker would actually want to achieve.
Is my website vulnerable?
Your website is vulnerable if your web server supports both:
- HTTPS on port 443 (standard secure web traffic)
- HTTP with TLS upgrade capability on port 80
Quick test:
curl -H "Upgrade: TLS/1.0" -i http://website.com
If you receive "101 Switching Protocols" in the response, your server supports TLS upgrade and is vulnerable. Most modern web servers have this feature disabled by default, but some configurations may have it enabled.
Note: The vast majority of websites are not vulnerable as HTTP TLS upgrade (RFC 2817) was never widely adopted and no browsers support it.
Is my browser vulnerable?
Your browser has no influence on whether you are vulnerable to the attack or not. As long as the server you are trying to connect to supports both implicit and opportunistic TLS, you can be attacked. There is nothing your browser can really do about this. The concrete impact then depends on the web application.
How do I fix the issue?
The best way to fix the issue is to disable opportunistic TLS in affected protocols and switch to implicit TLS. For HTTP, this means disabling the upgrade feature from RFC 2817.
Is TLS 1.3 also affected?
Yes, all versions of TLS are affected. The Opossum attack exploits how TLS is integrated into an application protocol and not the crypto itself.
How common is opportunistic TLS support?
Our Internet-wide scans found over 3 million hosts supporting both implicit and opportunistic TLS. However, most of it is on protocols for which we do not have a functioning exploit. This means that for now, the impact of the attack is low. For HTTP, we found only a small number of vulnerable servers.
Since when does the vulnerability exist?
The vulnerability has existed since opportunistic TLS was introduced. For HTTP, RFC 2817 (from 2000) introduced TLS upgrade. For email protocols, STARTTLS has been around since the late 1990s. The fundamental issue - supporting both implicit and opportunistic TLS simultaneously - has been a security risk for over two decades.
Why wasn't this discovered earlier?
The Opossum vulnerability builds upon the authentication issue identified in the ALPACA attack (2021). At the same time, RFC 2817 which really makes Opossum practically exploitable in HTTP is not very well known and was never implemented in browsers, and was therefore not on the watch of most security researchers. The more widespread issue in other protocols is not obviously exploitable, and (at the moment!), more of a concern for academics, protocol designers and theoreticians and may have gone under the radar because of that.
Can this be fixed in TLS?
It technically can, but the chances of this happening are likely low. A proper fix would require countermeasures for the ALPACA attack, as well as a separation of the opportunistic and implicit protocol variants on the ALPN strings.
Why is the attack called "Opossum"?
Giving attacks on standards names makes it easier to talk about. We named previous attacks after animals so we chose another one for this :3
How can I even configure RFC 2817 to be vulnerable?
A lot of web servers do not support RFC 2817. An example server can be configured with Apache2 by setting "SSLEngine optional".
How have vendors responded to this vulnerability?
We have responsibly disclosed our findings to relevant entities:
- BSI CERT was informed of the issue
- IETF is aware of the issue and will discuss deprecation.
- Apache Foundation. Plans deprecation. Issue is tracked as CVE-2025-49812
- Cyrus IMAPD. Fixed in versions 3.12.1, 3.10.2, and 3.8.6 (disabled STARTTLS by default)
- CUPS (Apple). Patch in progress
- Icecast. Patch in progress
Recommended Mitigation: Disable opportunistic TLS support and use only implicit TLS.