[2] An example of such a flaw was found in OpenSSL that allowed the attacker to negotiate the use of a lower version of TLS between the client and server.
Opportunistic encryption protocols such as STARTTLS are generally vulnerable to downgrade attacks, as they, by design, fall back to unencrypted communication.
[6] Researchers have classified downgrade attacks with respect to four different vectors, which represents a framework to reason about downgrade attacks as follows:[6] There are some recent proposals[7][8] that exploit the concept of prior knowledge to enable TLS clients (e.g. web browsers) to protect sensitive domain names against certain types of downgrade attacks that exploit the clients' support for legacy versions or non-recommended ciphersuites (e.g. those that do not support forward secrecy or authenticated encryption) such as the POODLE, ClientHello fragmentation,[9][10] and a variant of the DROWN (aka "the special drown") downgrade attacks.
[clarification needed] Removing backward compatibility is often the only way to prevent downgrade attacks.
For example, if a Web server and user agent both implement HTTP Strict Transport Security and the user agent knows this of the server (either by having previously accessed it over HTTPS, or because it is on an "HSTS preload list"[11][12][13]), then the user agent will refuse to access the site over vanilla HTTP, even if a malicious router represents it and the server to each other as not being HTTPS-capable.