Editing Transport Layer Security (section)

===={{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>