Downgrade attack

Last updated

A downgrade attack, also called a bidding-down attack, [1] or version rollback attack, is a form of cryptographic attack on a computer system or communications protocol that makes it abandon a high-quality mode of operation (e.g. an encrypted connection) in favor of an older, lower-quality mode of operation (e.g. cleartext) that is typically provided for backward compatibility with older systems. [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. [3] This is one of the most common types of downgrade attacks. Opportunistic encryption protocols such as STARTTLS are generally vulnerable to downgrade attacks, as they, by design, fall back to unencrypted communication. Websites which rely on redirects from unencrypted HTTP to encrypted HTTPS can also be vulnerable to downgrade attacks (e.g., sslstrip), as the initial redirect is not protected by encryption. [4]

Contents

Attack

Downgrade attacks are often implemented as part of a Man-in-the-middle (MITM) attack, and may be used as a way of enabling a cryptographic attack that might not be possible otherwise. [5] Downgrade attacks have been a consistent problem with the SSL/TLS family of protocols; examples of such attacks include the POODLE attack.

Downgrade attacks in the TLS protocol take many forms. [6] Researchers have classified downgrade attacks with respect to four different vectors, which represents a framework to reason about downgrade attacks as follows: [6]

  1. The protocol element that is targeted
    • Algorithm
    • Version
    • Layer
  2. The type of vulnerability that enables the attack
    • Implementation
    • Design
    • Trust-model
  3. The attack method
    • Dropping
    • Modification
    • Injection
  4. The level of damage that the attack causes
    • Broken Security
    • Weakened Security

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. However, sometimes the client and server can recognize each other as up-to-date in a manner that prevents them. 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.

See also

Related Research Articles

<span class="mw-page-title-main">HTTPS</span> Extension of the HTTP communications protocol to support TLS encryption

Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It uses encryption for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The protocol is therefore also referred to as HTTP over TLS, or HTTP over SSL.

In cryptography and computer security, a man-in-the-middle (MITM) attack, or on-path attack, is a cyberattack where the attacker secretly relays and possibly alters the communications between two parties who believe that they are directly communicating with each other, as the attacker has inserted themselves between the two parties.

Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.

<span class="mw-page-title-main">OpenSSL</span> Open-source implementation of the SSL and TLS protocols

OpenSSL is a software library for applications that provide secure communications over computer networks against eavesdropping, and identify the party at the other end. It is widely used by Internet servers, including the majority of HTTPS websites.

FTPS is an extension to the commonly used File Transfer Protocol (FTP) that adds support for the Transport Layer Security (TLS) and, formerly, the Secure Sockets Layer cryptographic protocols.

<span class="mw-page-title-main">Forward secrecy</span> Practice in cryptography

In cryptography, forward secrecy (FS), also known as perfect forward secrecy (PFS), is a feature of specific key-agreement protocols that gives assurances that session keys will not be compromised even if long-term secrets used in the session key exchange are compromised, limiting damage. For HTTPS, the long-term secret is typically the private key of the server. Forward secrecy protects past sessions against future compromises of keys or passwords. By generating a unique session key for every session a user initiates, the compromise of a single session key will not affect any data other than that exchanged in the specific session protected by that particular key. This by itself is not sufficient for forward secrecy which additionally requires that a long-term secret compromise does not affect the security of past session keys.

Opportunistic encryption (OE) refers to any system that, when connecting to another system, attempts to encrypt communications channels, otherwise falling back to unencrypted communications. This method requires no pre-arrangement between the two systems.

Opportunistic TLS refers to extensions in plain text communication protocols, which offer a way to upgrade a plain text connection to an encrypted connection instead of using a separate port for encrypted communication. Several protocols use a command named "STARTTLS" for this purpose. It is a form of opportunistic encryption and is primarily intended as a countermeasure to passive monitoring.

Server Name Indication (SNI) is an extension to the Transport Layer Security (TLS) computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. The extension allows a server to present one of multiple possible certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites to be served by the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS. This also allows a proxy to forward client traffic to the right server during TLS/SSL handshake. The desired hostname is not encrypted in the original SNI extension, so an eavesdropper can see which site is being requested. The SNI extension was specified in 2003 in RFC 3546

Obfuscated TCP (ObsTCP) was a proposal for a transport layer protocol which implements opportunistic encryption over Transmission Control Protocol (TCP). It was designed to prevent mass wiretapping and malicious corruption of TCP traffic on the Internet, with lower implementation cost and complexity than Transport Layer Security (TLS). In August 2008, IETF rejected the proposal for a TCP option, suggesting it be done on the application layer instead. The project has been inactive since a few months later.

HTTP Strict Transport Security (HSTS) is a policy mechanism that helps to protect websites against man-in-the-middle attacks such as protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers should automatically interact with it using only HTTPS connections, which provide Transport Layer Security (TLS/SSL), unlike the insecure HTTP used alone. HSTS is an IETF standards track protocol and is specified in RFC 6797.

A cipher suite is a set of algorithms that help secure a network connection. Suites typically use Transport Layer Security (TLS) or its deprecated predecessor Secure Socket Layer (SSL). The set of algorithms that cipher suites usually contain include: a key exchange algorithm, a bulk encryption algorithm, and a message authentication code (MAC) algorithm.

In computer networking, tcpcrypt is a transport layer communication encryption protocol. Unlike prior protocols like TLS (SSL), tcpcrypt is implemented as a TCP extension. It was designed by a team of six security and networking experts: Andrea Bittau, Mike Hamburg, Mark Handley, David Mazières, Dan Boneh and Quinn Slack. Tcpcrypt has been published as an Internet Draft. Experimental user-space implementations are available for Linux, Mac OS X, FreeBSD and Windows. There is also a Linux kernel implementation.

In cryptography, a padding oracle attack is an attack which uses the padding validation of a cryptographic message to decrypt the ciphertext. In cryptography, variable-length plaintext messages often have to be padded (expanded) to be compatible with the underlying cryptographic primitive. The attack relies on having a "padding oracle" who freely responds to queries about whether a message is correctly padded or not. The information could be directly given, or leaked through a side-channel.

CRIME is a security vulnerability in HTTPS and SPDY protocols that utilize compression, which can leak the content of secret web cookies. When used to recover the content of secret authentication cookies, it allows an attacker to perform session hijacking on an authenticated web session, allowing the launching of further attacks. CRIME was assigned CVE-2012-4929.

POODLE is a security vulnerability which takes advantage of the fallback to SSL 3.0. If attackers successfully exploit this vulnerability, on average, they only need to make 256 SSL 3.0 requests to reveal one byte of encrypted messages. Bodo Möller, Thai Duong and Krzysztof Kotowicz from the Google Security Team discovered this vulnerability; they disclosed the vulnerability publicly on October 14, 2014. On December 8, 2014, a variation of the POODLE vulnerability that affected TLS was announced.

FREAK is a security exploit of a cryptographic weakness in the SSL/TLS protocols introduced decades earlier for compliance with U.S. cryptography export regulations. These involved limiting exportable software to use only public key pairs with RSA moduli of 512 bits or fewer, with the intention of allowing them to be broken easily by the National Security Agency (NSA), but not by other organizations with lesser computing resources. However, by the early 2010s, increases in computing power meant that they could be broken by anyone with access to relatively modest computing resources using the well-known Number Field Sieve algorithm, using as little as $100 of cloud computing services. Combined with the ability of a man-in-the-middle attack to manipulate the initial cipher suite negotiation between the endpoints in the connection and the fact that the finished hash only depended on the master secret, this meant that a man-in-the-middle attack with only a modest amount of computation could break the security of any website that allowed the use of 512-bit export-grade keys. While the exploit was only discovered in 2015, its underlying vulnerabilities had been present for many years, dating back to the 1990s.

<span class="mw-page-title-main">DROWN attack</span> Security bug

The DROWN attack is a cross-protocol security bug that attacks servers supporting modern SSLv3/TLS protocol suites by using their support for the obsolete, insecure, SSL v2 protocol to leverage an attack on connections using up-to-date protocols that would otherwise be secure. DROWN can affect all types of servers that offer services encrypted with SSLv3/TLS yet still support SSLv2, provided they share the same public key credentials between the two protocols. Additionally, if the same public key certificate is used on a different server that supports SSLv2, the TLS server is also vulnerable due to the SSLv2 server leaking key information that can be used against the TLS server.

<span class="mw-page-title-main">J. Alex Halderman</span> American computer scientist

J. Alex Halderman is professor of computer science and engineering at the University of Michigan, where he is also director of the Center for Computer Security & Society. Halderman's research focuses on computer security and privacy, with an emphasis on problems that broadly impact society and public policy.

Version history for TLS/SSL support in web browsers tracks the implementation of Transport Layer Security protocol versions in major web browsers.

References

  1. "Security Implications of 5G Networks" (PDF). U C Berkeley Center for Long-Term Cybersecurity. Retrieved 24 November 2021.
  2. "Version rollback attack".
  3. Praetorian (19 August 2014). "Man-in-the-Middle TLS Protocol Downgrade Attack". Praetorian. Retrieved 13 April 2016.
  4. Mutton, Paul (17 March 2016). "95% of HTTPS servers vulnerable to trivial MITM attacks | Netcraft". www.netcraft.com. Retrieved 11 December 2023.
  5. "Downgrade attack". encyclopedia.kaspersky.com. Retrieved 5 September 2023.
  6. 1 2 Alashwali, E. S. and Rasmussen, K. (2018). What's in a Downgrade? A Taxonomy of Downgrade Attacks in the TLS Protocol and Application Protocols Using TLS. 4th Int. Workshop on Applications and Techniques in Cyber Security (ATCS) co-located with 14th Int. Conf. in Security and Privacy in Communication Networks (SecureComm). Springer. pp. 469–487. arXiv: 1809.05681 .{{cite conference}}: CS1 maint: multiple names: authors list (link)
  7. Alashwali, E. S. and Rasmussen, K. (2018). On the Feasibility of Fine-Grained TLS Security Configurations in Web Browsers Based on the Requested Domain Name. 14th Int. Conf. in Security and Privacy in Communication Networks (SecureComm). Springer. pp. 213–228. arXiv: 1809.05686 .{{cite conference}}: CS1 maint: multiple names: authors list (link)
  8. Alashwali, E. S. and Szalachowski, P. (2018). DSTC: DNS-based Strict TLS Configurations. 13th Int. Conf. on Risks and Security of Internet and Systems (CRISIS). Springer. arXiv: 1809.05674 .{{cite conference}}: CS1 maint: multiple names: authors list (link)
  9. ldapwiki. "ClientHello". Archived from the original on 17 March 2020. Retrieved 30 January 2019.
  10. Beurdouche, B., Delignat-Lavaud, A., Kobeissi, N., Pironti, A., Bhargavan, K. (2015). FLEXTLS A Tool for Testing TLS Implementations. 9th USENIX Workshop on Offensive Technologies ({WOOT} 15. USENIX. Retrieved 30 January 2019.{{cite conference}}: CS1 maint: multiple names: authors list (link)
  11. Adam Langley (8 July 2010). "Strict Transport Security". The Chromium Projects. Retrieved 22 July 2010.
  12. David Keeler (1 November 2012). "Preloading HSTS". Mozilla Security Blog. Retrieved 6 February 2014.
  13. Bell, Mike; Walp, David (16 February 2015). "HTTP Strict Transport Security comes to Internet Explorer" . Retrieved 16 February 2015.