{
	"id": "325756b5-1aed-435a-baff-134ddc235db5",
	"created_at": "2026-04-06T01:32:38.81839Z",
	"updated_at": "2026-04-10T03:22:00.536138Z",
	"deleted_at": null,
	"sha1_hash": "3e7c2d814124b421fe30e09a7b6bf0d56c70b2a2",
	"title": "Downgrade Attacks",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 719128,
	"plain_text": "Downgrade Attacks\r\nBy http://profiles.google.com/+?rel=author\r\nPublished: 2017-02-03 · Archived: 2026-04-06 01:17:07 UTC\r\nLast week we learned about Padding Oracle Attacks which use side-channel information related to ciphertext\r\nmessage padding in order to deduce the underlying plaintext message in a TLS communication. This week we will\r\nlearn about Downgrade Attacks that force a TLS server to choose weaker encryption and protocol suit thereby\r\nmaking it vulnerable to attacks like man-in-the-middle.\r\nWe begin with a brief introduction of Diffie-Hellman Key Exchange protocol commonly used in TLS and then\r\ndescribe the Logjam attack on Diffie-Hellman protocol which relies on pre-computation of discrete-logs of a 512-\r\nbit prime used in the protocol. Next we discuss about State-level Threats to Diffie-Hellman, where we show that\r\nthe pre-computation of discrete-logs is in the reach of current academic computation power. The practical\r\nconsequence is that 8% of the top 1 million websites that use HTTPS can be broken in real time.\r\nIn the remainder of the article, we discuss about Bleichenbacher Attack which is a padding oracle attack on\r\nPKCS#1 v1.5 padding used in SSLv2. We conclude with Drown Attack that uses Bleichenbacker attack to gain\r\naccess to RSA key of a TLS communication.\r\nDiffie-Hellman Cryptanalysis\r\nDiffie-Hellman is a cryptologic method used to confidentially generate a shared secret (encryption key) between\r\ntwo parties in a conversation. Because the shared secret is used to encrypt message traffic, the integrity of Diffie-Hellman is crucial to the security of TLS, where the confidentiality of communication depends heavily on the\r\nprocess of securely generating a shared encryption key.\r\nBackground: Diffie-Hellman Key Exchange\r\nThe genius of Diffie-Hellman lies in its adherence to the principle of perfect forward secrecy. The asymmetric\r\nkeys used to perform the key exchange can be deleted after the key exchange is completed, so there is no risk of a\r\nlater compromise enabling an attacker to break previous traffic. The agreed shared key is never transmitted, saved,\r\nor otherwise made observable across a communication channel, even if the adversary were to collect all encrypted\r\ndata in transit and recover all material stored at the endpoints, it would still not be able to break the encryption.\r\nThe mathematical underpinnings of Diffie-Hellman are relatively simple. See the following image for an\r\nillustration of the exchange that occurs when generating a shared secret. Note that the secret values, a and b, are\r\nnever transmitted nor shared between Alice and Bob.\r\nhttps://tlseminar.github.io/downgrade-attacks/\r\nPage 1 of 13\n\nImage Source: https://i.stack.imgur.com/uYqQe.png\r\nThe Diffie-Hellman Problem\r\nThe Diffie-Hellman problem (DHP) is as follows: Given an element 𝑔 and the values 𝑔\r\n𝑥\r\n, 𝑔\r\n𝑦\r\n what is the value of\r\n𝑔\r\n𝑥𝑦 ?\r\nClearly, if this problem were easy to solve, Diffie-Hellman would be useless, since any eavesdropping adversary\r\ncould then collect both 𝑔\r\n𝑥\r\n and 𝑔\r\n𝑦\r\n, compute 𝑔\r\n𝑥𝑦\r\n, and subsequently decrypt all of Alice and Bob’s communication.\r\nThe Discrete Logarithm Problem (DLP) is thus by far the most efficient means to solve DHP and requires that the\r\neavesdropping adversary compute 𝑥 given 𝑔 and 𝑔\r\n𝑥\r\n – still believed to be a hard problem in general. But, if 𝑝 is a\r\nweak prime (as explained below), it can solved in a reasonable amount of time with available computing\r\nresources.\r\nAdrian et al. published a paper in 2015 that demonstrated a weakness in Diffie-Hellman key exchange in the\r\nHandshake Protocol of TLS. In order to perform cryptanalysis in such a situation, an attacker must solve DLP by\r\ncomputing arbitrary discrete log values in real-time. While it is not known how to calculate discrete logs\r\nefficiently (and believed to be hard), the attack can be accelerated using precomputation.\r\nIndex Calculus\r\nWhile the logic behind the precomputation cryptanalysis is based on the General Number Field Sieve, we examine\r\nIndex Calculus, a simplified version of the same concept. Index Calculus involves two steps: sieving and linear\r\nalgebra. In the sieving step, the cryptanalyst chooses a multiplicative group of numbers and attempts to find\r\nnumbers that factor completely over this group. We can then express these numbers as linear combinations of logs\r\nof the multiplicative group elements. By finding many such numbers, we obtain equations in terms of logs of\r\nmultiplicative group elements. In the linear algebra step, we can use these equations to solve for values of the\r\nlogs. This allows us to generate a database of precomputed logs.\r\nActive Downgrade\r\nUsing precomputed discrete logs, an attacker can perform an active downgrade attack on a TLS connection.\r\nOperating as an in-the-middle attacker, the attacker intercepts a Client Hello message and alters it to instruct the\r\nhttps://tlseminar.github.io/downgrade-attacks/\r\nPage 2 of 13\n\nserver to use export-grade Diffie-Hellman, which uses 512-bit keys rather than 1024-bit or higher, which allows\r\nthe attacker to use the precomputed logs. During the Handshake Protocol, the attacker is able to solve the discrete\r\nlog problem and recover the master secret of that connection. This allows the attacker to communicate directly\r\nwith the client over an encrypted channel, while the client still thinks he/she is communicating with their intended\r\nserver.\r\nThe Logjam Attack: Step-by-Step\r\nAlt\r\nhttps://cryptologie.net/upload/logjam.png\r\n1. The Client sends a Client Hello message to the Server. This includes a list of all supported ciphersuites\r\nthat can be used to generate the shared secret and requests that one be selected by the Server to begin the\r\nDiffie-Hellman exchange.\r\n2. The adversary intercepts the Client Hello messages and alters the available ciphersuites to only include\r\n512-bit Diffie-Hellman, then forwards the altered Client Hello to the Server.\r\n3. The Server receives the Client Hello . Since only one ciphersuite is shown to be supported by the Client,\r\nthe Server agrees to 512-bit Diffie-Hellman and generates a 512-bit prime 𝑝 to be used in the key\r\nexchange.\r\n4. The adversary intercepts the ciphersuite confirmation message from the Server and alters it to reflect the\r\nclient’s original ciphersuite preference, selecting full-strength DHE. It also eavesdrops on the Server’s\r\nDiffie-Hellman communication to discern 𝑔 and 𝑔𝑏.\r\n5. The Client thinks it has received the proper Diffie-Hellman information from the Server and begins its half\r\nof the Diffie-Hellman exchange. Note that the 512-bit prime 𝑝 is still considered a valid prime for 1024-bit\r\nDHE. Meanwhile, the adversary is hard at work calculating the discrete log of 𝑔\r\n𝑏 mod𝑝\r\n512\r\n. Multiple\r\nfactors can contribute to reduce the time-complexity of this process.\r\n6. Once the adversary has determined the value of 𝑏, the Client and adversary begin communicating as\r\nthough the adversary is the Server.\r\nThe time-complexity of precomputation using the number field sieve is entirely dependent on the prime number\r\nused; as a result, any connections using the same prime can be quickly broken. The researchers behind Logjam\r\ndetected that millions of HTTPS, SSH, and VPN servers use the same prime numbers for Diffie-Hellman key\r\nexchange, rendering supposedly-secure communications vulnerable to Logjam.\r\nWeak Primes\r\nConsider a prime number 𝑝. In 1978, Pohlig and Hellman demonstrated that if all factors of 𝑝 − 1 are less than\r\nlog𝑐𝑝, the problem of solving the discrete logarithm mod𝑝 is in 𝑃. In general terms, this means an attacker can\r\ngreatly reduce the complexity of the discrete logarithm problem and thus conduct the Logjam attack in a shorter\r\nperiod of time. We’ll demonstrate with an example using a small prime.\r\nhttps://tlseminar.github.io/downgrade-attacks/\r\nPage 3 of 13\n\nLet 𝑝 = 31 and 𝑔 = 3. 𝑔 has order 30 → 𝑔\r\n30 = 1 mod𝑝\r\nThe factors of 30 = 2 ∗ 3 ∗ 5 are too small for the prime 𝑝 to be secure, allowing an attacker to convert the discrete\r\nlogarithm problem mod31 into problems mod2, 3, 5. With the help of the Chinese Remainder Theorem, an\r\nattacker can easily find 𝑥 given 𝑔 and 𝑔\r\n𝑥\r\n.\r\nA strong prime 𝑝 = 2𝑞 + 1 (𝑞 is prime) avoids this problem of reducibility by ensuring that (𝑝 − 1) ÷ 2 cannot be\r\ncomposite (and, by extension, that Pohlig-Hellman cannot obtain information from 𝑝).\r\nThis puts a server that supports export-grade DH and reuses weak primes at severe risk to a motivated attack.\r\nState-Level Threats to Diffie-Hellman\r\nCurrent Situation\r\nIn recent years, the general bar for internet security has raised substantially. HTTPS is now the norm for most\r\nheavily trafficked websites and is spreading through services such as Let’s Encrypt, that allow for domain owners\r\nto easily get SSL certificates for a website at no cost. In general, this trend looks positive: for key exchange\r\nprotocols, stronger 768 and 1024-bit groups are now the norm rather than the exception. Individual users and\r\ninstitutions have also begun to better understand the need for security and IPSec Virtual Private Networks (VPNs)\r\nand SSH connects are being more broadly practiced.\r\nAcademic Power\r\nWhile standards have advanced and security has increased in general, cryptanalysis techniques and computational\r\npower have also increased. Although ideas such as Moore’s Law, that computing power at a certain price level\r\neffectively doubles every 18 months, the practical implications are not as often taken into account. These days,\r\nDH-512 is easily within the reach of “academic power,” that is to say, within the reach of institutions with access\r\nto midsize computing facilities or individuals who can afford a few hundred thousand dollars of computing.\r\nWith recent hardware, to “crack” DH-512 takes 2.5 core-years in the sieving phase, 7.7 core-years in the linear\r\nalgebra phase, but only 10 core-minutes in the descent phase. So, given a 2000-3000 core cluster, all of the phases\r\ncombined except the descent phase takes about 140 hours.\r\nhttps://weakdh.org/weakdh-ccs-slides.pdf\u003e\r\nhttps://tlseminar.github.io/downgrade-attacks/\r\nPage 4 of 13\n\nHowever, the descent phase only takes about 70 seconds. What does this mean? That after 1 week of pre-computation, an individual calculation can be completed in about 70s. If this is combined with something called a\r\n“downgrade attack,” which will be described below, connections to about 8% of top 1 million sites that use\r\nHTTPS can be broken in real time.\r\nA “core-year” is a measure of the amount of work that an average computer core can complete in a year.\r\nTo give a point of reference in terms of concrete cost, a single-core Amazon EC2 instance costs about\r\n$0.02 / hours. To run that core for a year would cost about $0.02 * (24 *365) = $175. A core-day and a\r\ncore-minute are defined similarly.\r\nAlthough it may seem like this isn’t as serious of a problem, since current practice is usually to use DH-768 or DH-1024 –for example, 91.0% of IKEv2 servers support a 1024-bit connection– in actuality\r\neven those are vulnerable to attack. In 2009, a new record was achieved for integer factorization with a\r\n768 bit integer factorization completed with academic resources over the span of 2 years. This would\r\nimply that breaking DH-768 takes about 36,500 core-years in pre-computation and 2 core-days in\r\ndecent. As much as this sounds, it is only a few million dollars worth, which is well within reach of\r\nboth moderately-funded academics and moderately-motivated adversaries (and peanuts for an\r\norganization like the NSA).\r\nStructural Costs\r\nOk, so a DH-768 connection can probably be broken by a non-state-level actor, but what about a DH-1024\r\nconnection? Surely that is ok? Let’s take a look at the costliness of DH-1024 in comparison to 768-bit DH. The\r\nalgorithmic time complexity increases by a factor of about 1220, the space complexity by a factor of 95, leaving\r\nus with this:\r\nhttps://weakdh.org/weakdh-ccs-slides.pdf\r\nhttps://tlseminar.github.io/downgrade-attacks/\r\nPage 5 of 13\n\nAlthough the costs seem astronomically high, they are actually within the reach of a state-level actor. If we assume\r\nthat some special purpose ASICs are developed to help speed up the sieving pre-computation such that it can be\r\ncompleted in one year (this would cost around $8 million), and we get access to, say, a Titan supercomputer for\r\none year (at a cost of $122 million) to complete the linear algebra phase in one year, we find that we can complete\r\nall of our pre-computation for the small cost of $130 million dollars. Compare this cost to the budget of a state-level actor such as the NSA: their 2012 budget was $10.5 billion, making this computation just 1% of that budget.\r\nWhat’s so Good About Breaking One Group?\r\nBut, you might object, what is the value in doing this pre-computation and breaking one group? Doesn’t this just\r\nmean that the NSA can only break a couple connections per year? Unfortunately, no. As Edward Snowden said,\r\n“If performing number field sieve pre-computations for at least a small number of 1024-bit Diffie-Hellman groups\r\nis possible, breaking any key exchanges made with those groups in close to real time is no difficulty.” This is\r\nbecause once the pre-computations are completed for a single group, that work can then be used to crack\r\nnumerous connections.\r\nIKE (IPsec VPNs)\r\nLet’s now take a step back and look at IKE, the Internet Key Exchange, which perhaps is the most vulnerable to\r\nthese kinds of attacks. IKE is a protocol used, in the IPsec protocol, to create a “Security Association (SA),” which\r\nis just a set of shared security attributes between two network parties such as cryptographic algorithm being used,\r\nthe algorithm mode, credentials, etc. In order to establish the SA, two parties go through a process like this:\r\nhttps://weakdh.org/weakdh-ccs-slides.pdf\r\nhttps://tlseminar.github.io/downgrade-attacks/\r\nPage 6 of 13\n\nWhile the exact details of how the protocol works are not important, it is important to note that to perform IKE\r\npassive decryption, an adversary would have to have access to a known pre-shared key, both sides of the IKE\r\nhandshake, and both the handshake traffic and ESP traffic.\r\nAlso important to note is that the vast majority of IKE systems use one particular 1024-bit DH group, the Oakley\r\nGroup 2, for the protocol. We find that 86.1% of IKEv1 servers and 91.0% of IKEv2 servers support Oakley\r\nGroup 2, and 66.1% of IKEv1 servers and 63.9% of IKEv2 servers chose Oakley Group 2 for the protocol. This\r\nmeans that a state-level actor with access to the pre-shared key, both sides of the IKE handshake, and both the\r\nhandshake traffic and ESP traffic would be able to passively decrypt 66% of VPN server traffic…in near real-time.\r\nShow me the Adversary\r\nIs this all hypothetical? Does any such adversary actually exist?\r\nA 2012 Wired article revealed information that the NSA, several years before 2012, made an “enormous\r\nbreakthrough” in its ability to cryptanalyze current public encryption. While the exact details are not known, it\r\nmay be reasonable to assume that the NSA completed the pre-computation for a 1024-bit DH group, such as the\r\nOakley Group 2, allowing them passive decrypted access to a swath of internet traffic.\r\nhttps://weakdh.org/weakdh-ccs-slides.pdf\r\nThe impact of such a break to IKE has already been noted. Other protocols would also be vulnerable to the break.\r\nSSH, for example, supports Oakley Group 2, Oakley Group 14, or a server-defined group that is negotiated\r\nthrough a DH-GEX handshake. According to recent data, 21.8% of servers prefer Oakley Group 2, and 37.4%\r\nprefer the server-defined group. However, of that 37.4%, almost all of them just provided Oakley Group 2 rather\r\nthan a real custom group. Thus, a state-level attacker that performed the break could passively eavesdrop on\r\nconnections to 25.7% of all publicly accessible SSH servers.\r\nUnfortunately, HTTPS connections are similarly affected. Of the top 1 million site that support DHE, 84% use a\r\n1024-bit or smaller group, and 94% of those use one of five common groups. Thus, 17.9% of connections to the\r\ntop 1 million sites could be passively eavesdropped with the pre-computation for a single 1024-bit prime.\r\nMitigations\r\nIs there any hope that a connection can really be secure given this information? Luckily, some mitigations can be\r\nput into place. First, servers can move to using elliptic curve cryptography (ECC). A transition to a elliptic curve\r\nhttps://tlseminar.github.io/downgrade-attacks/\r\nPage 7 of 13\n\nDiffe-Hellman key exchange (ECDH) with appropriate parameters would thwart all known feasible cryptanalytic\r\nattacks as ECC discrete log algorithms don’t gain too much advantage from precomputation. When ECC is not an\r\noption, it is recommended that primes at least 2048 bits in length be used. It would be ideal if browser vendors and\r\nclients raise the minimum accepted size for DH groups to at least 1024 bits. If large primes are not supported, then\r\nalways use a fresh 1024-bit group to mitigate the efficacy of precomputation-based attacks. It is parameter reuse\r\nthat allows state-level attackers to easily perform wide-scale passive decryption.\r\nBleichenbacher’s Padding Oracle Attack\r\nBleichenbacher’s padding oracle attack is an adaptive chosen ciphertext attack against PKCS#1 v1.5, the RSA\r\npadding standard used in SSL and TLS. It enables decryption of RSA ciphertexts if a server distinguishes between\r\ncorrectly and incorrectly padded RSA plaintexts, and was termed the “million-message attack” upon its\r\nintroduction in 1998, after the number of decryption queries needed to deduce a plaintext. All widely used\r\nSSL/TLS servers include countermeasures against Bleichenbacher attacks.\r\nPKCS#1 v1.5 encryption padding\r\nBleichenbacher’s padding oracle attack relies on the structure of RSA PKCS#1 v1.5 padding. Although RSA\r\nPKCS#1 v2.0 implements OAEP, SSL/TLS still uses PKCS#1 v1.5. The PKCS#1 v1.5 encryption padding\r\nscheme randomizes encryptions by prepending a random padding string PS to a message k (here, a symmetric\r\nsession key) before RSA encryption:\r\n1. The plaintext message is k, 𝑙𝑘 = | 𝑘 | . The encrypter generates a random byte string PS, where |PS| ≥ 8,\r\n| 𝑃𝑆 | = 𝑙𝑚 − 3 − 𝑙𝑘 and 0x00 ∉ 𝑃𝑆[1], … , 𝑃𝑆[ | 𝑃𝑆 | ]\r\n2. The encryption block is 𝑚 = 00 || 02 || 𝑃𝑆 || 00 || 𝑘\r\n3. The ciphertext is computed as 𝑐 = 𝑚\r\n𝑒 mod𝑁. To decrypt such a ciphertext, the decrypter first computes\r\n𝑚 = 𝑐\r\n𝑑 mod𝑁. Then it checks whether the decrypted message m is correctly formatted as a PKCS#1 v1.5-\r\nencoded message. We say that the ciphertext c and the decrypted message bytes\r\n𝑚[1] | | 𝑚[2] | | … | | 𝑚[𝑙𝑚 ] are PKCS#1 v1.5 conformant if:\r\n𝑚[1] | | 𝑚[2] = 0x00 || 0x02 and 0x00 ∉ 𝑚[3], … , 𝑚[10]\r\nIf this condition holds, the decrypter searches for the first value i \u003e 10 such that 𝑚[𝑖] = 0x00 . Then, it\r\nextracts 𝑘 = 𝑚[𝑖 + 1] | | … | | 𝑚[𝑙𝑚 ]. Otherwise, the ciphertext is rejected.\r\nIn SSLv3 and TLS, RSA PKCS#1 v1.5 is used to encapsulate the premaster secret exchanged during the\r\nhandshake. Thus, k is interpreted as the premaster secret. In SSLv2, RSA PKCS#1 v1.5 is used for encapsulation\r\nof an equivalent key denoted the master_key.\r\nBleichenbacher attack\r\nBleichenbacher’s attack is a padding oracle attack; it exploits the fact that RSA ciphertexts should decrypt to\r\nPKCS#1 v1.5-compliant plaintexts. If an implementation receives an RSA ciphertext that decrypts to an invalid\r\nPKCS#1 v1.5 plaintext, it might naturally leak this information via an error message, by closing the connection, or\r\nhttps://tlseminar.github.io/downgrade-attacks/\r\nPage 8 of 13\n\nby taking longer to process the error condition. This behavior can leak information about the plaintext that can be\r\nmodeled as a cryptographic oracle for the decryption process. Bleichenbacher demonstrated how such an oracle\r\ncould be exploited to decrypt RSA ciphertexts.\r\nAlgorithm\r\nIn the simplest attack scenario, the attacker has a valid PKCS#1 v1.5 ciphertext 𝑐0 that they wish to decrypt to\r\ndiscover the message m0. They have no access to the private RSA key, but instead have access to an oracle, 𝛿, that\r\nwill decrypt a ciphertext c and inform the attacker whether the most significant two bytes match the required value\r\nfor a correct PKCS#1 v1.5 padding:\r\n𝛿(𝑐) = 1 if 𝑚 = 𝑐\r\n𝑑 mod𝑁 starts with 0x00~02 0\r\n𝛿(𝑐) = 0 otherwise .\r\nIf the oracle answers with 1, the attacker knows that 2𝐵 ≤ 𝑚 ≤ 3𝐵 − 1, where 𝐵 = 2\r\n8(𝑙𝑚 − 2)\r\n.\r\nThe attacker can take advantage of RSA malleability to generate new candidate ciphertexts for any s:\r\n𝑐 = (𝑐0· 𝑠𝑒) mod𝑁 = 𝑚0· 𝑠\r\n𝑒 mod𝑁\r\nThe attacker queries the oracle with c. If the oracle responds with 0, the attacker increments s and repeats the\r\nprevious step. Otherwise, the attacker learns that for some r, 2𝐵 ≤ 𝑚0 𝑠 − 𝑟𝑁 \u003c 3𝐵. This allows the attacker to\r\nreduce the range of possible solutions to:\r\n2𝐵 + 𝑟𝑁\r\n𝑠\r\n≤ 𝑚0 \u003c\r\n3𝐵 + 𝑟𝑁\r\n𝑠\r\nThe attacker proceeds by refining guesses for s and r values and successively decreasing the size of the interval\r\ncontaining 𝑚0. At some point the interval will contain a single valid value, 𝑚0. Bleichenbacher’s original paper\r\ndescribes this process in further detail.\r\nIt is worth noting that the author implemented a proof-of-concept of this attack on a custom padding oracle\r\nimplementation. Over a test set of various 512-bit and 1024-bit keys, between 300,000 and 2 million ciphertexts\r\nwere required to find the message. While the details of the custom oracle are not known, it is reasonable to assume\r\nthat this attack is feasible in more realistic scenarios.\r\nCountermeasures\r\nIn order to protect against this attack, the reciever must not leak information about the PKCS#1 v1.5 validity of\r\nthe ciphertext. The ciphertext does not decrypt to a valid message, so the decrypter generates a fake plaintext and\r\ncontinues the protocol with this decoy. The attacker should not be able to distinguish the resulting computation\r\nfrom a correctly decrypted ciphertext. In the case of SSL/TLS, the server generates a random premaster secret to\r\ncontinue the handshake if the decrypted ciphertext is invalid. The client will not possess the session key to send a\r\nvalid ClientFinished message and the connection will terminate.\r\nIn addition, newer versions of PKSC#1 describe a new padding type, called OAEP, which uses hash function to\r\nadd more internal redundancy. This greatly decreases the probability that random strings will result in valid\r\nhttps://tlseminar.github.io/downgrade-attacks/\r\nPage 9 of 13\n\npadding, effectively preventing the attack.\r\nSources of Further Reading\r\nPadding Oracle Attacks on RSA\r\nCryptopals Crypto Challenge: A Do-It-Yourself excercise on Bleichenbacher attack.\r\nEfficient padding oracle attacks on cryptographic hardware\r\nDROWN: Breaking TLS using SSLv2\r\nPaper Link | Website\r\nDROWN attack is inspired by Bleichenbacher’s padding oracle attack over SSLv2 which could decrypt an SSLv2\r\nRSA ciphertext. The attack was possible due to a flaw in SSLv2 protocol which revealed if the decrypted message\r\nwas conformant with PKCS#1 v1.5 padding or not, thus acting as a padding oracle. The padding scheme is shown\r\nbelow where first two bytes are fixed 0x00 0x02 followed by 8 bytes of random padding string succeeded by a\r\n0x00 byte. The remaining part of the message is the plaintext which may contain the key to be recovered. The\r\npadding scheme is shown below:\r\nPKCS#1 v1.5 Padding Scheme\r\nThe client in SSLv2 protocol sends ClientMasterKey message to SSLv2 server which the server decrypts and\r\nresponds with ServerVerify message which tells whether the ClientMasterKey message was conformant with the\r\npadding scheme.\r\nThe figure below depicts the SSLv2 protocol. The attacker can modify the original ClientMasterKey message and\r\nif the SSLv2 server confirms the padding, the attacker would immediately get to know that the first two bytes of\r\nthe modified message is ‘0x00 0x02’. This way, the attacker can repeatedly modify the original message and\r\nquery the oracle. After multiple successful guesses for modified message, the attacker can narrow down the\r\nguesses for the original message and recover the master_key.\r\nhttps://tlseminar.github.io/downgrade-attacks/\r\nPage 10 of 13\n\nFlaw in SSLv2 protocol where the server reveals the correctness of padding\r\nSource: https://tlseminar.github.io/docs/drown.pdf\r\nMoreover, SSLv2 allowed export-grade ciphersuites which supported 40-bit key. A Bleichenbacher attacker could\r\nbrute-force the key by repeatedly querying the SSLv2 server.\r\nTLS patched the above flaws and (most) servers made the SSLv2 protocol obsolete. However, it was not\r\nuncommon for TLS servers to share same RSA keys with SSLv2 servers. This made the TLS servers vulnerable to\r\na modified form of Bleichenbacher attack which uses a SSLv2 server as padding oracle to decrypt the shared RSA\r\nkey. DROWN instantiated this protocol-level attack and decrypted a TLS 1.2 handshake using 2048-bit RSA in 8\r\nhours at a cost of $440 on Amazon EC2. As if this wasn’t devastating enough, the authors of DROWN pointed out\r\nsome implementation bugs in OpenSSL which lead to another attack called Special DROWN that could decrypt a\r\nTLS ciphertext in under 1 minute using a single CPU. Both the attacks are described below.\r\nDROWN Attack\r\nDROWN attack requires that a TLS server and a SSLv2 server share an RSA key. The attacker records multiple\r\nTLS handshake messages between a client and the TLS server. The aim of the attacker is to decrypt the RSA key\r\nof the TLS handshake. To do so, the attacker forces the client to establish a connection with an SSLv2 server\r\nhaving the same RSA key so that the attacker can initiate the Bleichenbacher attack to recover the RSA key.\r\nhttps://tlseminar.github.io/downgrade-attacks/\r\nPage 11 of 13\n\nNow the main hurdle for the attacker is that the format of TLS handshake message may not comply with PKCS#1\r\nv1.5 padding scheme of SSLv2. The attacker converts the TLS ciphertext to SSLv2 ciphertext using the concept of\r\ntrimmers introduced by Bardou et al. which reduces the size of the TLS message. The use of trimmers require\r\nrepeated querying to SSLv2 server by shifting the message bytes. The recovered SSLv2 plaintext is then\r\nconverted back to TLS plaintext which reveals the RSA key of TLS handshake.\r\nSSLv2-based Bleichenbacher attack on TLS\r\nSource: https://tlseminar.github.io/docs/drown.pdf\r\nSpecial DROWN Attack\r\nhttps://tlseminar.github.io/downgrade-attacks/\r\nPage 12 of 13\n\nThe OpenSSL implementation had two bugs which led to a more efficient Bleichenbacher attack on an OpenSSL\r\nimplementation of SSLv2 server.\r\nOpenSSL extra clear oracle: OpenSSL implementation allowed non-export cipher messages to contain\r\nclear_key_data which lead to potential overwriting of key bytes with null bytes. An attacker could vary the\r\nnumber of null bytes to decrypt the whole key one byte at a time.\r\nOpenSSL leaky export oracle: OpenSSL in export cipher mode allowed valid oracle response for correctly\r\npadded message of ‘any’ length.\r\nThese bugs remained in OpenSSL implementation from 1998 up until its patch in 2015, when the authors of\r\nDROWN contacted the OpenSSL developers.\r\nPrevention of DROWN\r\nThe attack is successful mainly because of the reliance on obsolete cryptographic practices. Export-grade ciphers\r\nonly support 40-bit keys which are vulnerable to brute-force attack and hence it is crucial to disable export-grade\r\nciphers and use safer ciphers (like AES_GCM) with longer key lengths (256-bits). PKCS#1 v1.5 padding leaks\r\nsignificant byte patterns and hence a better padding technique should be used. SSLv2 protocol includes the above\r\nobsolete cryptos and hence it should be scrapped and replaced with TLS 1.3. Lastly, the RSA public keys should\r\nnot be shared among multiple servers or connections in order to deter the attack.\r\nSource: https://tlseminar.github.io/downgrade-attacks/\r\nhttps://tlseminar.github.io/downgrade-attacks/\r\nPage 13 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://tlseminar.github.io/downgrade-attacks/"
	],
	"report_names": [
		"downgrade-attacks"
	],
	"threat_actors": [],
	"ts_created_at": 1775439158,
	"ts_updated_at": 1775791320,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/3e7c2d814124b421fe30e09a7b6bf0d56c70b2a2.pdf",
		"text": "https://archive.orkl.eu/3e7c2d814124b421fe30e09a7b6bf0d56c70b2a2.txt",
		"img": "https://archive.orkl.eu/3e7c2d814124b421fe30e09a7b6bf0d56c70b2a2.jpg"
	}
}