In software security, downgrade attacks are network attacks that force victims to use older, more vulnerable versions of software in order to exploit known vulnerabilities against them.
This has been especially dangerous in TLS clients supporting both modern and earlier versions of TLS, the latter being vulnerable to known network attacks. You can find more information about the imperfections of older TLS versions in our TLS 1.0 deprecation article.
In a man–in–the–middle (or MITM) attack, communication between two devices in a computer network is compromised by a third party – the “man in the middle.” In a passive MITM attack attackers “tap” the communication, capturing information in transit without changing it. If attackers attempt to to modify or tamper with the information itself they are committing an active MITM attack.
MITM attacks exploit the fact that a computer network can be manipulated in such a way that all network devices send their traffic to the attacker instead of the router or other nodes. A very common way to launch a MITM attack is by creating a fake node on an publicly-available computer network, such as a coffeeshop’s WiFi network.
Being a “man in the middle,” the attacker can manipulate the intercepted content as they see fit before relaying it to its intended destination. In most cases, victims of a MITM attack will never be aware that they are under attack.
HTTPS (via SSL/TLS) protects against MITM attacks by encrypting all data with a secret key that is only known to the original client and server. MITM attackers are not able to read or tamper with the encrypted data without knowledge of this secret key.
TLS 1.3 offers a feature called 0-RTT (zero round trip time) Resumption mode, in an effort to enhance performance.
When a browser successfully completes a TLS handshake with a server for the first time, both the client and the server can store a pre-shared encryption key locally. This is known as the resumption master secret.
If the browser establishes a connection with the server again at a later time, it can use this resumption key to send encrypted application data in its first message to the server, without having to perform the handshake a second time.
However, 0-RTT resumption has a caveat; resumption data require no interaction from the server, which means that an attacker can capture encrypted 0-RTT data and re-send them to the server, or replay them.
In the case the server is misconfigured, it can potentially accept replayed requests as valid; essentially, allowing the attackers to perform unsanctioned actions.
The solution to this issue is ensuring that all 0-RTT requests are idempotent.
Idempotent requests can be safely used as 0-RTT requests, since replaying them will have no effect. A quick rule of thumb would be to only use GET requests with 0-RTT resumption.
In computer science, an operation is idempotent if it can be performed multiple times without having a different result than the first time it was run.
For example, a POST HTTPS request that updates a counter in the database is not idempotent because it alters the state of the web application, while a GET request to the main web page is.