Editing Transport Layer Security (section)

===Attacks against TLS/SSL===
Significant attacks against TLS/SSL are listed below.

In February 2015, IETF issued an informational RFC<ref>{{cite ietf|rfc=7457|title=Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)|year=2015 |doi=10.17487/RFC7457 |last1=Sheffer |first1=Y. |last2=Holz |first2=R. |last3=Saint-Andre |first3=P. }}</ref> summarizing the various known attacks against TLS/SSL.

====Renegotiation attack====
A vulnerability of the renegotiation procedure was discovered in August 2009 that can lead to plaintext injection attacks against SSL 3.0 and all current versions of TLS.<ref>{{cite web|url=http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555|title=CVE – CVE-2009-3555|url-status=live|archive-url=https://web.archive.org/web/20160104234608/http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555|archive-date=2016-01-04}}</ref> For example, it allows an attacker who can hijack an [[https]] connection to splice their own requests into the beginning of the conversation the client has with the web server. The attacker cannot actually decrypt the client–server communication, so it is different from a typical [[man-in-the-middle attack]]. A short-term fix is for web servers to stop allowing renegotiation, which typically will not require other changes unless [[client certificate]] authentication is used. To fix the vulnerability, a renegotiation indication extension was proposed for TLS. It will require the client and server to include and verify information about previous handshakes in any renegotiation handshakes.<ref>{{cite web|first=Eric|last=Rescorla|title=Understanding the TLS Renegotiation Attack|work=Educated Guesswork|access-date=2009-11-27|date=2009-11-05|url=http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html|url-status=live|archive-url=https://web.archive.org/web/20120211120608/http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html|archive-date=2012-02-11}}</ref> This extension has become a proposed standard and has been assigned the number {{IETF RFC|5746}}. The RFC has been implemented by several libraries.<ref>{{cite web|title=SSL_CTX_set_options SECURE_RENEGOTIATION|work=OpenSSL Docs|access-date=2010-11-18|date=2010-02-25|url=https://www.openssl.org/docs/ssl/SSL_CTX_set_options.html#SECURE_RENEGOTIATION|url-status=live|archive-url=https://web.archive.org/web/20101126121933/http://openssl.org/docs/ssl/SSL_CTX_set_options.html#SECURE_RENEGOTIATION|archive-date=2010-11-26}}</ref><ref>{{cite web|title=GnuTLS 2.10.0 released|work=GnuTLS release notes|access-date=2011-07-24|date=2010-06-25|url=http://article.gmane.org/gmane.network.gnutls.general/2046|url-status=live|archive-url=https://web.archive.org/web/20151017033726/http://article.gmane.org/gmane.network.gnutls.general/2046|archive-date=2015-10-17}}</ref><ref>{{cite web|title=NSS 3.12.6 release notes|work=NSS release notes|access-date=2011-07-24|date=2010-03-03|url=https://developer.mozilla.org/NSS_3.12.6_release_notes|url-status=dead|archive-url=https://web.archive.org/web/20120306184633/https://developer.mozilla.org/NSS_3.12.6_release_notes|archive-date=March 6, 2012}}</ref>

===={{Anchor|Downgrade attacks}}Downgrade attacks: {{Anchor|FREAK}}FREAK attack and {{Anchor|Logjam attack|Logjam}}Logjam attack====
{{Main|Downgrade attack|FREAK|Logjam (computer security)}}
A protocol [[downgrade attack]] (also called a version rollback attack) tricks a web server into negotiating connections with previous versions of TLS (such as SSLv2) that have long since been abandoned as insecure.

Previous modifications to the original protocols, like '''False Start'''<ref>{{cite journal|title=Transport Layer Security (TLS) False Start|url=http://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00|journal=Internet Engineering Task Force|publisher=IETF|access-date=2013-07-31|author1=A. Langley|author2=N. Modadugu|author3=B. Moeller|date=2010-06-02|url-status=live|archive-url=https://web.archive.org/web/20130905215608/http://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00|archive-date=2013-09-05}}</ref> (adopted and enabled by Google Chrome<ref>{{cite web|first=Wolfgang|last=Gruener|title=False Start: Google Proposes Faster Web, Chrome Supports It Already|url=http://www.conceivablytech.com/3299/products/false-start-google-proposes-faster-web-chrome-supports-it-already|access-date=2011-03-09|archive-url=https://web.archive.org/web/20101007061707/http://www.conceivablytech.com/3299/products/false-start-google-proposes-faster-web-chrome-supports-it-already|archive-date=2010-10-07}}</ref>) or '''Snap Start''', reportedly introduced limited TLS protocol downgrade attacks<ref>{{cite web|first=Brian|last=Smith|title=Limited rollback attacks in False Start and Snap Start|url=http://www.ietf.org/mail-archive/web/tls/current/msg06933.html|access-date=2011-03-09|url-status=live|archive-url=https://web.archive.org/web/20110504014418/http://www.ietf.org/mail-archive/web/tls/current/msg06933.html|archive-date=2011-05-04}}</ref> or allowed modifications to the cipher suite list sent by the client to the server. In doing so, an attacker might succeed in influencing the cipher suite selection in an attempt to downgrade the cipher suite negotiated to use either a weaker symmetric encryption algorithm or a weaker key exchange.<ref>{{cite web|first=Adrian|last=Dimcev|title=False Start|url=http://www.carbonwind.net/blog/post/Random-SSLTLS-101-False-Start.aspx|work=Random SSL/TLS 101|access-date=2011-03-09|url-status=live|archive-url=https://web.archive.org/web/20110504060256/http://www.carbonwind.net/blog/post/Random-SSLTLS-101-False-Start.aspx|archive-date=2011-05-04}}</ref> A paper presented at an [[Association for Computing Machinery|ACM]] [[Computer security conference|conference on computer and communications security]] in 2012 demonstrated that the False Start extension was at risk: in certain circumstances it could allow an attacker to recover the encryption keys offline and to access the encrypted data.<ref>{{cite book|author1=Mavrogiannopoulos, Nikos|author2=Vercautern, Frederik|author3=Velichkov, Vesselin|author4=Preneel, Bart|title=A cross-protocol attack on the TLS protocol. Proceedings of the 2012 ACM conference on Computer and communications security|year=2012|isbn=978-1-4503-1651-4|url=https://www.cosic.esat.kuleuven.be/publications/article-2216.pdf|pages=62–72|publisher=Association for Computing Machinery |url-status=live|archive-url=https://web.archive.org/web/20150706104327/https://www.cosic.esat.kuleuven.be/publications/article-2216.pdf|archive-date=2015-07-06}}</ref>

Encryption downgrade attacks can force servers and clients to negotiate a connection using cryptographically weak keys. In 2014, a [[man-in-the-middle]] attack called FREAK was discovered affecting the [[OpenSSL]] stack, the default [[Android (operating system)|Android]] web browser, and some [[Safari (web browser)|Safari]] browsers.<ref>{{cite web|title=SMACK: State Machine AttaCKs|url=https://www.smacktls.com|url-status=live|archive-url=https://web.archive.org/web/20150312074827/https://www.smacktls.com|archive-date=2015-03-12}}</ref> The attack involved tricking servers into negotiating a TLS connection using cryptographically weak 512 bit encryption keys.

Logjam is a [[security exploit]] discovered in May 2015 that exploits the option of using legacy [[Arms Export Control Act|"export-grade"]] 512-bit [[Diffie–Hellman key exchange|Diffie–Hellman]] groups dating back to the 1990s.<ref>{{cite web|url=https://arstechnica.com/security/2015/05/https-crippling-attack-threatens-tens-of-thousands-of-web-and-mail-servers|title=HTTPS-crippling attack threatens tens of thousands of Web and mail servers|first=Dan|last=Goodin|work=Ars Technica|date=2015-05-20|url-status=live|archive-url=https://web.archive.org/web/20170519130937/https://arstechnica.com/security/2015/05/https-crippling-attack-threatens-tens-of-thousands-of-web-and-mail-servers|archive-date=2017-05-19}}</ref> It forces susceptible servers to downgrade to cryptographically weak 512-bit Diffie–Hellman groups. An attacker can then deduce the keys the client and server determine using the [[Diffie–Hellman key exchange]].

====Cross-protocol attacks: DROWN====
{{Main|DROWN attack}}
The [[DROWN attack]] is an exploit that attacks servers supporting contemporary SSL/TLS protocol suites by exploiting their support for the obsolete, insecure, SSLv2 protocol to leverage an attack on connections using up-to-date protocols that would otherwise be secure.<ref>{{cite web|url=https://www.theregister.com/2016/03/01/drown_tls_protocol_flaw|title=One-third of all HTTPS websites open to DROWN attack|last=Leyden|first=John|date=1 March 2016|website=The Register|access-date=2016-03-02|url-status=live|archive-url=https://web.archive.org/web/20160301215536/http://www.theregister.co.uk/2016/03/01/drown_tls_protocol_flaw|archive-date=1 March 2016}}</ref><ref name=ars201603>{{cite web|url=https://arstechnica.com/information-technology/2016/03/more-than-13-million-https-websites-imperiled-by-new-decryption-attack|title=More than 11 million HTTPS websites imperiled by new decryption attack|website=Ars Technica|date=March 2016|access-date=2016-03-02|url-status=live|archive-url=https://web.archive.org/web/20160301191108/http://arstechnica.com/security/2016/03/more-than-13-million-https-websites-imperiled-by-new-decryption-attack|archive-date=2016-03-01}}</ref> DROWN exploits a vulnerability in the protocols used and the configuration of the server, rather than any specific implementation error. Full details of DROWN were announced in March 2016, together with a patch for the exploit. At that time, more than 81,000 of the top 1 million most popular websites were among the TLS protected websites that were vulnerable to the DROWN attack.<ref name=ars201603/>

===={{Anchor|BEAST}}BEAST attack====
On September 23, 2011, researchers Thai Duong and Juliano Rizzo demonstrated a proof of concept called '''BEAST''' ('''Browser Exploit Against SSL/TLS''')<ref name=DuongRizzo>{{cite web|url=https://bug665814.bugzilla.mozilla.org/attachment.cgi?id=540839|title=Here Come The ⊕ Ninjas|date=2011-05-13|author1=Thai Duong|author2=Juliano Rizzo|name-list-style=amp|url-status=live|archive-url=https://web.archive.org/web/20140603102506/https://bug665814.bugzilla.mozilla.org/attachment.cgi?id=540839|archive-date=2014-06-03}}</ref> using a [[Java applet]] to violate [[same origin policy]] constraints, for a long-known [[cipher block chaining]] (CBC) vulnerability in TLS 1.0:<ref name=DanGoodin>{{cite web|url=https://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl|title=Hackers break SSL encryption used by millions of sites|date=2011-09-19|first=Dan|last=Goodin|website=[[The Register]]|url-status=live|archive-url=https://web.archive.org/web/20120210185309/http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl|archive-date=2012-02-10}}</ref><ref name=combinator>{{cite web|url=http://news.ycombinator.com/item?id=3015498|title=Y Combinator comments on the issue|date=2011-09-20|url-status=live|archive-url=https://web.archive.org/web/20120331225714/http://news.ycombinator.com/item?id=3015498|archive-date=2012-03-31}}</ref> an attacker observing 2 consecutive ciphertext blocks C0, C1 can test if the plaintext block P1 is equal to x by choosing the next plaintext block {{nowrap|1=P2 = x ⊕ C0 ⊕ C1}}; as per CBC operation, {{nowrap|1=C2 = E(C1 ⊕ P2) = E(C1 ⊕ x ⊕ C0 ⊕ C1) = E(C0 ⊕ x)}}, which will be equal to C1 if {{nowrap|1=x = P1}}. Practical [[exploit (computer security)|exploits]] had not been previously demonstrated for this [[vulnerability (computing)|vulnerability]], which was originally discovered by [[Phillip Rogaway]]<ref>{{cite web|url=http://www.openssl.org/~bodo/tls-cbc.txt|archive-url=https://web.archive.org/web/20120630143111/http://www.openssl.org/~bodo/tls-cbc.txt|archive-date=2012-06-30|title=Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures|date=2004-05-20}}</ref> in 2002. The vulnerability of the attack had been fixed with TLS 1.1 in 2006, but TLS 1.1 had not seen wide adoption prior to this attack demonstration.

[[RC4]] as a stream cipher is immune to BEAST attack. Therefore, RC4 was widely used as a way to mitigate BEAST attack on the server side. However, in 2013, researchers found more weaknesses in RC4. Thereafter enabling RC4 on server side was no longer recommended.<ref>{{cite web|url=https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat|title=Is BEAST Still a Threat?|date=Sep 10, 2013|access-date=8 October 2014|last=Ristic|first=Ivan|url-status=live|archive-url=https://web.archive.org/web/20141012121824/https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat|archive-date=12 October 2014}}</ref>

Chrome and Firefox themselves are not vulnerable to BEAST attack,<ref name=ChromeBEAST>{{cite web|url=http://googlechromereleases.blogspot.jp/2011/10/chrome-stable-release.html|title=Chrome Stable Release|work=Chrome Releases|date=2011-10-25|access-date=2015-02-01|url-status=live|archive-url=https://web.archive.org/web/20150220020306/http://googlechromereleases.blogspot.jp/2011/10/chrome-stable-release.html|archive-date=2015-02-20}}</ref><ref name=FirefoxBEAST>{{cite web|url=https://blog.mozilla.org/security/2011/09/27/attack-against-tls-protected-communications|title=Attack against TLS-protected communications|work=Mozilla Security Blog|publisher=Mozilla|date=2011-09-27|access-date=2015-02-01|url-status=live|archive-url=https://web.archive.org/web/20150304221307/https://blog.mozilla.org/security/2011/09/27/attack-against-tls-protected-communications|archive-date=2015-03-04}}</ref> however, Mozilla updated their [[Network Security Services|NSS]] libraries to mitigate BEAST-like [[Attack (computing)|attacks]]. NSS is used by [[Mozilla Firefox]] and [[Google Chrome]] to implement SSL. Some [[web server]]s that have a broken implementation of the SSL specification may stop working as a result.<ref>{{cite web|url=https://bugzilla.mozilla.org/show_bug.cgi?id=665814|title=(CVE-2011-3389) Rizzo/Duong chosen plaintext attack (BEAST) on SSL/TLS 1.0 (facilitated by websockets-76)|date=2011-09-30|first=Brian|last=Smith|access-date=2011-11-01|archive-date=2012-02-10|archive-url=https://web.archive.org/web/20120210202750/https://bugzilla.mozilla.org/show_bug.cgi?id=665814|url-status=live}}</ref>

[[Microsoft]] released Security Bulletin MS12-006 on January 10, 2012, which fixed the BEAST vulnerability by changing the way that the Windows Secure Channel ([[Schannel]]) component transmits encrypted network packets from the server end.<ref name=MS12-006>{{cite tech report|author=MSRC|author-link=Microsoft Security Response Center|date=2012-01-10|url=https://docs.microsoft.com/en-us/security-updates/SecurityBulletins/2012/ms12-006|title=Vulnerability in SSL/TLS Could Allow Information Disclosure (2643584)|website=Security Bulletins|number=MS12-006|access-date=2021-10-24|via=[[Microsoft Docs]]}}</ref> Users of Internet Explorer (prior to version 11) that run on older versions of Windows ([[Windows 7]], [[Windows 8]] and [[Windows Server 2008|Windows Server 2008 R2]]) can restrict use of TLS to 1.1 or higher.

[[Apple Inc.|Apple]] fixed BEAST vulnerability by implementing 1/n-1 split and turning it on by default in [[OS X Mavericks]], released on October 22, 2013.<ref>{{cite web|url=https://community.qualys.com/blogs/securitylabs/2013/10/31/apple-enabled-beast-mitigations-in-os-x-109-mavericks|title=Apple Enabled BEAST Mitigations in OS X 10.9 Mavericks|date=Oct 31, 2013|access-date=8 October 2014|last=Ristic|first=Ivan|url-status=live|archive-url=https://web.archive.org/web/20141012122536/https://community.qualys.com/blogs/securitylabs/2013/10/31/apple-enabled-beast-mitigations-in-os-x-109-mavericks|archive-date=12 October 2014}}</ref>

===={{Anchor|CRIME attack|BREACH attack|CRIME|BREACH}} CRIME and BREACH attacks====<!--This Anchor tag serves to provide a permanent target for incoming section links. Please do not move it out of the section heading, even though it disrupts edit summary generation (you can manually fix the edit summary before saving your changes). Please do not modify it, even if you modify the section title. It is always best to anchor an old section header that has been changed so that links to it won't be broken. See [[Template:Anchor]] for details. (This text: [[Template:Anchor comment]])-->
{{Main|CRIME|BREACH}}
The authors of the BEAST attack are also the creators of the later [[CRIME]] attack, which can allow an attacker to recover the content of web cookies when [[data compression]] is used along with TLS.<ref>{{cite web|url=https://arstechnica.com/security/2012/09/crime-hijacks-https-sessions|title=Crack in Internet's foundation of trust allows HTTPS session hijacking|website=Ars Technica|first=Dan|last=Goodin|date=2012-09-13|access-date=2013-07-31|url-status=live|archive-url=https://web.archive.org/web/20130801104610/http://arstechnica.com/security/2012/09/crime-hijacks-https-sessions|archive-date=2013-08-01}}</ref><ref>{{cite web|url=http://threatpost.com/en_us/blogs/crime-attack-uses-compression-ratio-tls-requests-side-channel-hijack-secure-sessions-091312|title=CRIME Attack Uses Compression Ratio of TLS Requests as Side Channel to Hijack Secure Sessions|publisher=ThreatPost|date=September 13, 2012|last=Fisher|first=Dennis|access-date=2012-09-13|url-status=dead|archive-url=https://web.archive.org/web/20120915224635/http://threatpost.com/en_us/blogs/crime-attack-uses-compression-ratio-tls-requests-side-channel-hijack-secure-sessions-091312|archive-date=September 15, 2012}}</ref> When used to recover the content of secret [[authentication cookie]]s, it allows an attacker to perform [[session hijacking]] on an authenticated web session.

While the CRIME attack was presented as a general attack that could work effectively against a large number of protocols, including but not limited to TLS, and application-layer protocols such as [[SPDY]] or [[HTTP]], only exploits against TLS and SPDY were demonstrated and largely mitigated in browsers and servers. The CRIME exploit against [[HTTP compression]] has not been mitigated at all, even though the authors of CRIME have warned that this vulnerability might be even more widespread than SPDY and TLS compression combined. In 2013 a new instance of the CRIME attack against HTTP compression, dubbed [[BREACH]], was announced. Based on the CRIME attack a BREACH attack can extract login tokens, email addresses or other sensitive information from TLS encrypted web traffic in as little as 30 seconds (depending on the number of bytes to be extracted), provided the attacker tricks the victim into visiting a malicious web link or is able to inject content into valid pages the user is visiting (ex: a wireless network under the control of the attacker).<ref name=Gooin20130801>{{cite web|last=Goodin|first=Dan|title=Gone in 30 seconds: New attack plucks secrets from HTTPS-protected pages|url=https://arstechnica.com/security/2013/08/gone-in-30-seconds-new-attack-plucks-secrets-from-https-protected-pages|work=Ars Technica|publisher=Condé Nast|access-date=2 August 2013|date=1 August 2013|url-status=live|archive-url=https://web.archive.org/web/20130803181144/http://arstechnica.com/security/2013/08/gone-in-30-seconds-new-attack-plucks-secrets-from-https-protected-pages|archive-date=3 August 2013}}</ref> All versions of TLS and SSL are at risk from BREACH regardless of the encryption algorithm or cipher used.<ref>{{cite web|last=Leyden|first=John|title=Step into the BREACH: New attack developed to read encrypted web data|url=https://www.theregister.co.uk/2013/08/02/breach_crypto_attack|work=The Register|access-date=2 August 2013|date=2 August 2013|url-status=live|archive-url=https://web.archive.org/web/20130805233414/http://www.theregister.co.uk/2013/08/02/breach_crypto_attack|archive-date=5 August 2013}}</ref> Unlike previous instances of CRIME, which can be successfully defended against by turning off TLS compression or SPDY header compression, BREACH exploits HTTP compression which cannot realistically be turned off, as virtually all web servers rely upon it to improve data transmission speeds for users.<ref name=Gooin20130801/> This is a known limitation of TLS as it is susceptible to [[chosen-plaintext attack]] against the application-layer data it was meant to protect.

====Timing attacks on padding====
Earlier TLS versions were vulnerable against the [[padding oracle attack]] discovered in 2002. A novel variant, called the [[Lucky Thirteen attack]], was published in 2013.

Some experts<ref name="best-practices"/> also recommended avoiding [[triple DES]] CBC. Since the last supported ciphers developed to support any program using [[Windows XP]]'s SSL/TLS library like Internet Explorer on Windows XP are [[RC4]] and Triple-DES, and since RC4 is now deprecated (see discussion of [[talk:RC4|RC4 attacks]]), this makes it difficult to support any version of SSL for any program using this library on XP.

A fix was released as the Encrypt-then-MAC extension to the TLS specification, released as {{IETF RFC|7366}}.<ref>{{cite IETF|publisher=Internet Engineering Task Force|rfc=7366|title=Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)|date=September 2014|author=P. Gutmann}}</ref> The Lucky Thirteen attack can be mitigated in TLS 1.2 by using only AES_GCM ciphers; AES_CBC remains vulnerable. SSL may safeguard email, VoIP, and other types of communications over insecure networks in addition to its primary use case of secure data transmission between a client and the server.<ref name=":0" />

===={{Anchor|POODLE}}POODLE attack====
{{Main|POODLE}}
On October 14, 2014, Google researchers published a vulnerability in the design of SSL 3.0, which makes [[CBC mode of operation]] with SSL 3.0 vulnerable to a [[padding oracle attack|padding attack]] ({{CVE|2014-3566}}). They named this attack '''POODLE''' ('''Padding Oracle On Downgraded Legacy Encryption'''). On average, attackers only need to make 256 SSL 3.0 requests to reveal one byte of encrypted messages.<ref name="poodle_pdf">{{cite web|url=https://www.openssl.org/~bodo/ssl-poodle.pdf|title=This POODLE Bites: Exploiting The SSL 3.0 Fallback|author1=Bodo Möller, Thai Duong|author2=Krzysztof Kotowicz|name-list-style=amp|access-date=2014-10-15|url-status=live|archive-url=https://web.archive.org/web/20141014224443/https://www.openssl.org/~bodo/ssl-poodle.pdf|archive-date=2014-10-14}}</ref>

Although this vulnerability only exists in SSL 3.0 and most clients and servers support TLS 1.0 and above, all major browsers voluntarily downgrade to SSL 3.0 if the handshakes with newer versions of TLS fail unless they provide the option for a user or administrator to disable SSL 3.0 and the user or administrator does so{{citation needed|date=February 2015}}. Therefore, the man-in-the-middle can first conduct a [[version rollback attack]] and then exploit this vulnerability.<ref name="poodle_pdf"/>

On December 8, 2014, a variant of POODLE was announced that impacts TLS implementations that do not properly enforce padding byte requirements.<ref name="poodleagain">{{cite web|url=https://www.imperialviolet.org/2014/12/08/poodleagain.html|title=The POODLE bites again|date=December 8, 2014|last=Langley|first=Adam|access-date=2014-12-08|url-status=live|archive-url=https://web.archive.org/web/20141208200653/https://www.imperialviolet.org/2014/12/08/poodleagain.html|archive-date=December 8, 2014}}</ref>

===={{Anchor|RC4}}RC4 attacks====
{{Main|RC4#Security}}
Despite the existence of attacks on [[RC4]] that broke its security, cipher suites in SSL and TLS that were based on RC4 were still considered secure prior to 2013 based on the way in which they were used in SSL and TLS. In 2011, the RC4 suite was actually recommended as a workaround for the [[BEAST (computer security)|BEAST]] attack.<ref>{{Cite web|url=https://serverfault.com/questions/315042/safest-ciphers-to-use-with-the-beast-tls-1-0-exploit-ive-read-that-rc4-is-im|title=ssl – Safest ciphers to use with the BEAST? (TLS 1.0 exploit) I've read that RC4 is immune|website=Serverfault.com|access-date=20 February 2022|archive-date=20 February 2022|archive-url=https://web.archive.org/web/20220220210446/https://serverfault.com/questions/315042/safest-ciphers-to-use-with-the-beast-tls-1-0-exploit-ive-read-that-rc4-is-im|url-status=live}}</ref> New forms of attack disclosed in March 2013 conclusively demonstrated the feasibility of breaking RC4 in TLS, suggesting it was not a good workaround for BEAST.<ref name="community.qualys"/> An attack scenario was proposed by AlFardan, Bernstein, Paterson, Poettering and Schuldt that used newly discovered statistical biases in the RC4 key table<ref>{{cite book|contribution=Discovery and Exploitation of New Biases in RC4|author1=Pouyan Sepehrdad|author2=Serge Vaudenay|author3=Martin Vuagnoux|title=Selected Areas in Cryptography: 17th International Workshop, SAC 2010, Waterloo, Ontario, Canada, August 12–13, 2010, Revised Selected Papers|series=Lecture Notes in Computer Science|editor1=Alex Biryukov|editor2=Guang Gong|editor2-link=Guang Gong|editor3=Douglas R. Stinson|year=2011|volume=6544|pages=74–91|doi=10.1007/978-3-642-19574-7_5|isbn=978-3-642-19573-0}}</ref> to recover parts of the plaintext with a large number of TLS encryptions.<ref>{{cite web|url=http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html|title=Attack of the week: RC4 is kind of broken in TLS|work=Cryptography Engineering|access-date=March 12, 2013|last=Green|first=Matthew|date=12 March 2013|url-status=live|archive-url=https://web.archive.org/web/20130314214026/http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html|archive-date=March 14, 2013}}</ref><ref>{{cite web|title=On the Security of RC4 in TLS|url=http://www.isg.rhul.ac.uk/tls|publisher=Royal Holloway University of London|access-date=March 13, 2013|first1=Nadhem|last1=AlFardan|first2=Dan|last2=Bernstein|first3=Kenny|last3=Paterson|first4=Bertram|last4=Poettering|first5=Jacob|last5=Schuldt|url-status=live|archive-url=https://web.archive.org/web/20130315084623/http://www.isg.rhul.ac.uk/tls|archive-date=March 15, 2013}}</ref> An attack on RC4 in TLS and SSL that requires 13 × 2<sup>20</sup> encryptions to break RC4 was unveiled on 8 July 2013 and later described as "feasible" in the accompanying presentation at a [[USENIX]] Security Symposium in August 2013.<ref>{{cite journal|first1=Nadhem J.|last1=AlFardan|first2=Daniel J.|last2=Bernstein|first3=Kenneth G.|last3=Paterson|first4=Bertram|last4=Poettering|first5=Jacob C. N.|last5=Schuldt|date=8 July 2013|title=On the Security of RC4 in TLS and WPA|access-date=2 September 2013|url=http://www.isg.rhul.ac.uk/tls/RC4biases.pdf|journal=Information Security Group|url-status=live|archive-url=https://web.archive.org/web/20130922170155/http://www.isg.rhul.ac.uk/tls/RC4biases.pdf|archive-date=22 September 2013}}</ref><ref>{{cite conference|url=https://www.usenix.org/sites/default/files/conference/protected-files/alfardan_sec13_slides.pdf|title=On the Security of RC4 in TLS|first1=Nadhem J.|last1=AlFardan|first2=Daniel J.|last2=Bernstein|first3=Kenneth G.|last3=Paterson|first4=Bertram|last4=Poettering|first5=Jacob C. N.|last5=Schuldt|date=15 August 2013|conference=22nd [[USENIX]] Security Symposium|access-date=2 September 2013|quote=Plaintext recovery attacks against RC4 in TLS are feasible although not truly practical|page=51|url-status=live|archive-url=https://web.archive.org/web/20130922133950/https://www.usenix.org/sites/default/files/conference/protected-files/alfardan_sec13_slides.pdf|archive-date=22 September 2013}}</ref> In July 2015, subsequent improvements in the attack make it increasingly practical to defeat the security of RC4-encrypted TLS.<ref>{{cite web|last1=Goodin|first1=Dan|title=Once-theoretical crypto attack against HTTPS now verges on practicality|url=https://arstechnica.com/security/2015/07/once-theoretical-crypto-attack-against-https-now-verges-on-practicality|website=[[Ars Technica]]|date=15 July 2015|publisher=Conde Nast|access-date=16 July 2015|url-status=live|archive-url=https://web.archive.org/web/20150716084138/http://arstechnica.com/security/2015/07/once-theoretical-crypto-attack-against-https-now-verges-on-practicality|archive-date=16 July 2015}}</ref>

As many modern browsers have been designed to defeat BEAST attacks (except Safari for Mac OS X 10.7 or earlier, for iOS 6 or earlier, and for Windows; see {{section link||Web browsers}}), RC4 is no longer a good choice for TLS 1.0. The CBC ciphers which were affected by the BEAST attack in the past have become a more popular choice for protection.<ref name="best-practices"/> Mozilla and Microsoft recommend disabling RC4 where possible.<ref>{{cite web|url=https://wiki.mozilla.org/Security/Server_Side_TLS|title=Mozilla Security Server Side TLS Recommended Configurations|publisher=Mozilla|access-date=2015-01-03|url-status=live|archive-url=https://web.archive.org/web/20150103093047/https://wiki.mozilla.org/Security/Server_Side_TLS|archive-date=2015-01-03}}</ref><ref>{{cite web|url=http://blogs.technet.com/b/srd/archive/2013/11/12/security-advisory-2868725-recommendation-to-disable-rc4.aspx|title=Security Advisory 2868725: Recommendation to disable RC4|date=2013-11-12|publisher=Microsoft|access-date=2013-12-04|url-status=live|archive-url=https://web.archive.org/web/20131118081816/http://blogs.technet.com/b/srd/archive/2013/11/12/security-advisory-2868725-recommendation-to-disable-rc4.aspx|archive-date=2013-11-18}}</ref> {{IETF RFC|7465}} prohibits the use of RC4 cipher suites in all versions of TLS.

On September 1, 2015, Microsoft, Google, and Mozilla announced that RC4 cipher suites would be disabled by default in their browsers ([[Microsoft Edge Legacy|Microsoft Edge [Legacy]]], [[Internet Explorer 11]] on Windows 7/8.1/10, [[Firefox]], and [[Google Chrome|Chrome]]) in early 2016.<ref>{{cite web|url=https://blogs.windows.com/msedgedev/2015/09/01/ending-support-for-the-rc4-cipher-in-microsoft-edge-and-internet-explorer-11|title=Ending support for the RC4 cipher in Microsoft Edge and Internet Explorer 11|publisher=Microsoft Edge Team|date=September 1, 2015|url-status=live|archive-url=https://web.archive.org/web/20150902054341/http://blogs.windows.com/msedgedev/2015/09/01/ending-support-for-the-rc4-cipher-in-microsoft-edge-and-internet-explorer-11|archive-date=September 2, 2015}}</ref><ref>{{cite web|url=https://groups.google.com/a/chromium.org/forum/#!msg/security-dev/kVfCywocUO8/vgi_rQuhKgAJ|title=Intent to deprecate: RC4|date=Sep 1, 2015|last=Langley|first=Adam|access-date=September 2, 2015|archive-date=May 23, 2013|archive-url=https://web.archive.org/web/20130523081122/http://groups.google.com/a/chromium.org/group/chromium-os-dev/browse_thread/thread/337cca9a0da59ad6/9354a38894da5df5#!msg/security-dev/kVfCywocUO8/vgi_rQuhKgAJ|url-status=live}}</ref><ref>{{cite web|title=Intent to ship: RC4 disabled by default in Firefox 44|url=https://groups.google.com/forum/#!topic/mozilla.dev.platform/JIEFcrGhqSM/discussion|date=Sep 1, 2015|last=Barnes|first=Richard|url-status=live|archive-url=http://arquivo.pt/wayback/20110122130054/https://groups.google.com/forum/#!topic/mozilla.dev.platform/JIEFcrGhqSM/discussion|archive-date=2011-01-22}}</ref>

====Truncation attack====
A TLS (logout) truncation attack blocks a victim's account logout requests so that the user unknowingly remains logged into a web service. When the request to sign out is sent, the attacker injects an unencrypted [[Transmission Control Protocol|TCP]] FIN message (no more data from sender) to close the connection. The server therefore does not receive the logout request and is unaware of the abnormal termination.<ref name=register20130801>{{cite web|title=Gmail, Outlook.com and e-voting 'pwned' on stage in crypto-dodge hack|url=https://www.theregister.co.uk/2013/08/01/gmail_hotmail_hijacking|work=The Register|access-date=1 August 2013|author=John Leyden|date=1 August 2013|url-status=live|archive-url=https://web.archive.org/web/20130801193054/http://www.theregister.co.uk/2013/08/01/gmail_hotmail_hijacking|archive-date=1 August 2013}}</ref>

Published in July 2013,<ref>{{cite web|title=BlackHat USA Briefings|url=https://www.blackhat.com/us-13/briefings.html#Smyth|work=Black Hat 2013|access-date=1 August 2013|url-status=live|archive-url=https://web.archive.org/web/20130730124037/http://www.blackhat.com/us-13/briefings.html#Smyth|archive-date=30 July 2013}}</ref><ref>{{cite thesis|last1=Smyth|first1=Ben|last2=Pironti|first2=Alfredo|title=Truncating TLS Connections to Violate Beliefs in Web Applications|journal=7th USENIX Workshop on Offensive Technologies|date=2013|url=https://hal.inria.fr/hal-01102013|access-date=15 February 2016|url-status=live|archive-url=https://web.archive.org/web/20151106110117/https://hal.inria.fr/hal-01102013|archive-date=6 November 2015|type=report}}</ref> the attack causes web services such as [[Gmail]] and [[outlook.com|Hotmail]] to display a page that informs the user that they have successfully signed-out, while ensuring that the user's browser maintains authorization with the service, allowing an attacker with subsequent access to the browser to access and take over control of the user's logged-in account. The attack does not rely on installing malware on the victim's computer; attackers need only place themselves between the victim and the web server (e.g., by setting up a rogue wireless hotspot).<ref name=register20130801/> This vulnerability also requires access to the victim's computer.
Another possibility is when using FTP the data connection can have a false FIN in the data stream, and if the protocol rules for exchanging close_notify alerts is not adhered to a file can be truncated.

====Plaintext attack against DTLS====
In February 2013 two researchers from Royal Holloway, University of London discovered a timing attack<ref name="praad-tls">{{cite conference |title=Plaintext-recovery attacks against datagram TLS |last1=AlFardan |first1=Nadhem |last2=Paterson |first2=Kenneth G |conference=Network and distributed system security symposium (NDSS 2012) |year=2012 | url=http://www.isg.rhul.ac.uk/~kp/dtls.pdf | archive-url=https://web.archive.org/web/20120118070007/http://www.isg.rhul.ac.uk/~kp/dtls.pdf | archive-date=2012-01-18 | url-status=unfit}}</ref> which allowed them to recover (parts of the) plaintext from a DTLS connection using the OpenSSL or GnuTLS implementation of DTLS when [[Cipher Block Chaining]] mode encryption was used.

====Unholy PAC attack====
This attack, discovered in mid-2016, exploits weaknesses in the [[Web Proxy Autodiscovery Protocol]] (WPAD) to expose the URL that a web user is attempting to reach via a TLS-enabled web link.<ref>{{cite web|last1=Goodin|first1=Dan|title=New attack bypasses HTTPS protection on Macs, Windows, and Linux|url=https://arstechnica.com/security/2016/07/new-attack-that-cripples-https-crypto-works-on-macs-windows-and-linux|website=Ars Technica|date=26 July 2016|publisher=Condé Nast|access-date=28 July 2016|url-status=live|archive-url=https://web.archive.org/web/20160727160434/http://arstechnica.com/security/2016/07/new-attack-that-cripples-https-crypto-works-on-macs-windows-and-linux|archive-date=27 July 2016}}</ref> Disclosure of a URL can violate a user's privacy, not only because of the website accessed, but also because URLs are sometimes used to authenticate users. Document sharing services, such as those offered by Google and Dropbox, also work by sending a user a security token that is included in the URL. An attacker who obtains such URLs may be able to gain full access to a victim's account or data.

The exploit works against almost all browsers and operating systems.

====Sweet32 attack====
The Sweet32 attack breaks all 64-bit block ciphers used in CBC mode as used in TLS by exploiting a [[birthday attack]] and either a [[man-in-the-middle attack]] or injection of a malicious [[JavaScript]] into a web page. The purpose of the man-in-the-middle attack or the JavaScript injection is to allow the attacker to capture enough traffic to mount a birthday attack.<ref>{{Cite news|url=https://arstechnica.com/security/2016/08/new-attack-can-pluck-secrets-from-1-of-https-traffic-affects-top-sites|title=HTTPS and OpenVPN face new attack that can decrypt secret cookies|first=Dan|last=Goodin|newspaper=Ars Technica|date=August 24, 2016|access-date=August 24, 2016|url-status=live|archive-url=https://web.archive.org/web/20160824181630/http://arstechnica.com/security/2016/08/new-attack-can-pluck-secrets-from-1-of-https-traffic-affects-top-sites|archive-date=August 24, 2016}}</ref>

====Implementation errors: {{Anchor|Heartbleed}}Heartbleed bug, {{Anchor|BERserk}}BERserk attack, Cloudflare bug====
{{Main|Heartbleed|Cloudbleed}}
The [[Heartbleed]] bug is a serious vulnerability specific to the implementation of SSL/TLS in the popular [[OpenSSL]] cryptographic software library, affecting versions 1.0.1 to 1.0.1f. This weakness, reported in April 2014, allows attackers to steal [[Public-key cryptography|private keys]] from servers that should normally be protected.<ref>{{cite news|url=https://www.washingtonpost.com/blogs/style-blog/wp/2014/04/09/why-is-it-called-the-heartbleed-bug|title=Why is it called the 'Heartbleed Bug'?|newspaper=The Washington Post|date=2014-04-09|url-status=live|archive-url=https://web.archive.org/web/20141009063758/http://www.washingtonpost.com/blogs/style-blog/wp/2014/04/09/why-is-it-called-the-heartbleed-bug|archive-date=2014-10-09}}</ref> The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret private keys associated with the [[X.509|public certificates]] used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.<ref>{{cite web|url=https://blogs.comodo.com/e-commerce/heartbleed-bug-comodo-urges-openssl-users-to-apply-patch|title=Heartbleed Bug vulnerability [9 April 2014]|publisher=[[Comodo Group]]|url-status=live|archive-url=https://web.archive.org/web/20140705212748/https://blogs.comodo.com/e-commerce/heartbleed-bug-comodo-urges-openssl-users-to-apply-patch|archive-date=5 July 2014}}</ref> The vulnerability is caused by a [[buffer over-read]] bug in the OpenSSL software, rather than a defect in the SSL or TLS protocol specification.

In September 2014, a variant of [[Daniel Bleichenbacher]]'s PKCS#1 v1.5 RSA Signature Forgery vulnerability<ref>{{cite web|url=http://www.imc.org/ietf-openpgp/mail-archive/msg06063.html|title=Bleichenbacher's RSA signature forgery based on implementation error|date=August 2006|first=Daniel|last=Bleichenbacher|author-link=Daniel Bleichenbacher|url-status=dead|archive-url=https://web.archive.org/web/20141216203704/http://www.imc.org/ietf-openpgp/mail-archive/msg06063.html|archive-date=2014-12-16}}</ref> was announced by Intel Security Advanced Threat Research. This attack, dubbed BERserk, is a result of incomplete ASN.1 length decoding of public key signatures in some SSL implementations, and allows a man-in-the-middle attack by forging a public key signature.<ref>{{cite web|url=http://www.intelsecurity.com/advanced-threat-research|title=BERserk|date=September 2014|publisher=Intel Security: Advanced Threat Research|url-status=live|archive-url=https://web.archive.org/web/20150112153121/http://www.intelsecurity.com/advanced-threat-research|archive-date=2015-01-12}}</ref>

In February 2015, after media reported the hidden pre-installation of [[superfish]] adware on some Lenovo notebooks,<ref>{{cite web|url=https://arstechnica.com/information-technology/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-breaks-https-connections|title=Lenovo PCs ship with man-in-the-middle adware that breaks HTTPS connections|last=Goodin|first=Dan|date=February 19, 2015|website=[[Ars Technica]]|access-date=December 10, 2017|url-status=live|archive-url=https://web.archive.org/web/20170912103610/https://arstechnica.com/information-technology/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-breaks-https-connections|archive-date=September 12, 2017}}</ref> a researcher found a trusted root certificate on affected Lenovo machines to be insecure, as the keys could easily be accessed using the company name, Komodia, as a passphrase.<ref>{{cite web|first=Filippo|last=Valsorda|url=https://blog.filippo.io/komodia-superfish-ssl-validation-is-broken|title=Komodia/Superfish SSL validation is broken|publisher=Filippo.io|date=2015-02-20|url-status=live|archive-url=https://web.archive.org/web/20150224112141/https://blog.filippo.io/komodia-superfish-ssl-validation-is-broken|archive-date=2015-02-24}}</ref> The Komodia library was designed to intercept client-side TLS/SSL traffic for parental control and surveillance, but it was also used in numerous adware programs, including Superfish, that were often surreptitiously installed unbeknownst to the computer user. In turn, these [[potentially unwanted program]]s installed the corrupt root certificate, allowing attackers to completely control web traffic and confirm false websites as authentic.

In May 2016, it was reported that dozens of Danish HTTPS-protected websites belonging to [[Visa Inc.]] were vulnerable to attacks allowing hackers to inject malicious code and forged content into the browsers of visitors.<ref name="forbidden">{{cite web|last1=Goodin|first1=Dan|title="Forbidden attack" makes dozens of HTTPS Visa sites vulnerable to tampering|url=https://arstechnica.com/security/2016/05/faulty-https-settings-leave-dozens-of-visa-sites-vulnerable-to-forgery-attacks|website=Ars Technica|date=26 May 2016|access-date=26 May 2016|url-status=live|archive-url=https://web.archive.org/web/20160526175713/http://arstechnica.com/security/2016/05/faulty-https-settings-leave-dozens-of-visa-sites-vulnerable-to-forgery-attacks|archive-date=26 May 2016}}</ref> The attacks worked because the TLS implementation used on the affected servers incorrectly reused random numbers ([[cryptographic nonce|nonces]]) that are intended to be used only once, ensuring that each [[#TLS handshake|TLS handshake]] is unique.<ref name=forbidden/>

In February 2017, an implementation error caused by a single mistyped character in code used to parse HTML created a buffer overflow error on [[Cloudflare]] servers. Similar in its effects to the Heartbleed bug discovered in 2014, this overflow error, widely known as [[Cloudbleed]], allowed unauthorized third parties to read data in the memory of programs running on the servers—data that should otherwise have been protected by TLS.<ref>{{cite web|last1=Clark Estes|first1=Adam|title=Everything You Need to Know About Cloudbleed, the Latest Internet Security Disaster|url=https://gizmodo.com/everything-you-need-to-know-about-cloudbleed-the-lates-1792710616|website=[[Gizmodo]]|date=February 24, 2017|access-date=2017-02-24|url-status=live|archive-url=https://web.archive.org/web/20170225013516/http://gizmodo.com/everything-you-need-to-know-about-cloudbleed-the-lates-1792710616|archive-date=2017-02-25}}</ref>

====Survey of websites vulnerable to attacks====
{{As of|2021|07}}, the Trustworthy Internet Movement estimated the ratio of websites that are vulnerable to TLS attacks.<ref name="trustworthy_ssl_pulse"/>
{|class="wikitable"style=text-align:center
|+Survey of the TLS vulnerabilities of the most popular websites
|-
!scope=col rowspan=2|Attacks
!scope=col colspan=4|Security
|-
!scope=col|Insecure
!scope=col|Depends
!scope=col|Secure
!scope=col|Other
|-
!scope=row|[[#Renegotiation attack|Renegotiation attack]]
|{{Bad|< 0.1%<br />support insecure renegotiation}}
|{{Partial|< 0.1%<br />support both}}
|{{Good|99.7%<br />support secure renegotiation}}
|{{CNone|0.3%<br />no support}}
|-
!scope=row|[[#RC4 attacks|RC4 attacks]]
|{{Bad|0.2%<br />support RC4 suites used with modern browsers}}
|{{Partial|3.0%<br />support some RC4 suites}}
|{{Good|96.9%<br />no support}}
|{{N/A}}
|-
!scope=row|[[#CRIME attack|TLS Compression (CRIME attack)]]
|{{Bad|0%<br />vulnerable}}
|{{N/A}}
|{{N/A}}
|{{N/A}}
|-
!scope=row|[[#Heartbleed|Heartbleed]]
|{{Bad|0%<br />vulnerable}}
|{{N/A}}
|{{N/A}}
|{{N/A}}
|-
!scope=row|[[CVE-2014-0224|ChangeCipherSpec injection attack]]
|{{Bad|< 0.1%<br />vulnerable and exploitable}}
|{{Partial|< 0.1%<br />vulnerable, not exploitable}}
|{{Good|99.5%<br />not vulnerable}}
|{{unknown|0.4%<br />unknown}}
|-
!scope=row|[[#POODLE attack|POODLE attack against TLS]]<br /><small>(Original POODLE against SSL 3.0 is not included)</small>
|{{Bad|< 0.1%<br />vulnerable and exploitable}}
|{{N/A}}
|{{Good|99.9%<br />not vulnerable}}
|{{unknown|0.1%<br />unknown}}
|-
!scope=row|[[#Downgrade attacks|Protocol downgrade]]
|{{Bad|4.1%<br />Downgrade defence not supported}}
|{{N/A}}
|{{Good|80.2%<br />Downgrade defence supported}}
|{{unknown|15.7%<br />unknown}}
|}