Editing Transport Layer Security (section)

===TLS 1.3===
TLS 1.3 was defined in RFC 8446 in August 2018.{{Ref RFC|8446}} It is based on the earlier TLS 1.2 specification. Major differences from TLS 1.2 include:<ref name="WolfSSL, 2019">{{cite web|url=https://www.wolfssl.com/differences-between-tls-12-and-tls-13-9|title=Differences between TLS 1.2 and TLS 1.3 (#TLS13)|access-date=2019-09-18|date=2019-09-18|website=WolfSSL|archive-url=https://web.archive.org/web/20190919000200/https://www.wolfssl.com/differences-between-tls-12-and-tls-13-9|archive-date=2019-09-19}}</ref>
*Separating key agreement and authentication algorithms from the cipher suites<ref name="urlnvlpubs.nist.gov" />{{Ref RFC|8446|rsection=11}}
*Removing support for weak and less-used named [[elliptic-curve cryptography|elliptic curves]]
*Removing support for MD5 and SHA-224 [[cryptographic hash function]]s
*Requiring digital signatures even when a previous configuration is used
*Integrating [[HKDF]] and the semi-ephemeral DH proposal
*Replacing resumption with [[TLS-PSK|PSK]] and tickets
*Supporting 1-[[round-trip delay time|RTT]] handshakes and initial support for 0-[[round-trip delay time|RTT]]
*Mandating perfect [[forward secrecy]], by means of using ephemeral keys during the (EC)DH key agreement
*Dropping support for many insecure or obsolete features including [[data compression|compression]], renegotiation, non-[[authenticated encryption|AEAD]] ciphers, [[Null encryption|null cipher]]s,<ref>{{Cite web |url=https://datatracker.ietf.org/meeting/116/materials/slides-116-tls-null-encryption-and-key-exchange-without-forward-secrecy-are-discouraged-00 |title=Archived copy |access-date=2024-03-17 |archive-date=2024-03-17 |archive-url=https://web.archive.org/web/20240317154304/https://datatracker.ietf.org/meeting/116/materials/slides-116-tls-null-encryption-and-key-exchange-without-forward-secrecy-are-discouraged-00 |url-status=live }}</ref> non-[[forward secrecy|PFS]] key exchange (among which are static [[RSA (cryptosystem)|RSA]] and static [[Diffie–Hellman key exchange|DH]] key exchanges), custom [[Diffie–Hellman key exchange|DHE]] groups, EC point format negotiation, Change Cipher Spec protocol, Hello message UNIX time, and the length field AD input to AEAD ciphers
*Prohibiting SSL or RC4 negotiation for backwards compatibility
*Integrating use of session hash
*Deprecating use of the record layer version number and freezing the number for improved backwards compatibility
*Moving some security-related algorithm details from an appendix to the specification and relegating ClientKeyShare to an appendix
*Adding the [[ChaCha20]] stream cipher with the [[Poly1305]] message authentication code
*Adding the [[Ed25519]] and [[Ed448]] digital signature algorithms
*Adding the [[x25519]] and [[x448]] key exchange protocols
*Adding support for sending multiple [[Online Certificate Status Protocol|OCSP]] responses
*Encrypting all handshake messages after the ServerHello, including [[server certificate]]

[[Network Security Services]] (NSS), the cryptography library developed by [[Mozilla]] and used by its web browser [[Firefox]], enabled TLS 1.3 by default in February 2017.<ref name=NSS-3.29>{{cite web|url=https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.29_release_notes|title=NSS 3.29 release notes|date=February 2017|publisher=Mozilla Developer Network|url-status=live|archive-url=https://web.archive.org/web/20170222052829/https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.29_release_notes|archive-date=2017-02-22}}</ref> TLS 1.3 support was subsequently added — but due to compatibility issues for a small number of users, not automatically enabled<ref>{{cite web|url=https://bugzilla.mozilla.org/show_bug.cgi?id=1310516|title=Enable TLS 1.3 by default|date=16 October 2016|publisher=Bugzilla@Mozilla|access-date=10 October 2017|archive-date=12 August 2018|archive-url=https://web.archive.org/web/20180812021410/https://bugzilla.mozilla.org/show_bug.cgi?id=1310516|url-status=live}}</ref> — to [[History of Firefox#Firefox 52 through 59|Firefox 52.0]], which was released in March 2017. TLS 1.3 was enabled by default in May 2018 with the release of [[History of Firefox#Firefox 60 through 67|Firefox 60.0]].<ref>{{cite web|url=https://www.mozilla.org/en-US/firefox/60.0/releasenotes|title=Firefox — Notes (60.0)|website=Mozilla|language=en-US|access-date=2018-05-10|archive-date=2018-05-09|archive-url=https://web.archive.org/web/20180509230339/https://www.mozilla.org/en-US/firefox/60.0/releasenotes/|url-status=live}}</ref>

[[Google Chrome]] set TLS 1.3 as the default version for a short time in 2017. It then removed it as the default, due to incompatible middleboxes such as [[Blue Coat Systems|Blue Coat web proxies]].<ref>{{cite web|url=http://bluecoat.force.com/knowledgebase/articles/Technical_Alert/000032878|title=ProxySG, ASG and WSS will interrupt SSL connections when clients using TLS 1.3 access sites also using TLS 1.3|date=16 May 2017|work=BlueTouch Online|access-date=11 September 2017|url-status=live|archive-url=https://web.archive.org/web/20170912061432/http://bluecoat.force.com/knowledgebase/articles/Technical_Alert/000032878|archive-date=12 September 2017}}</ref>

The intolerance of the new version of TLS was [[protocol ossification]]; middleboxes had ossified the protocol's version parameter. As a result, version 1.3 mimics the [[wire image (networking)|wire image]] of version 1.2. This change occurred very late in the design process, only having been discovered during browser deployment.<ref>{{Cite web|url=https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet/|title=Why TLS 1.3 isn't in browsers yet|date=2017-12-26|website=The Cloudflare Blog|language=en|access-date=2020-03-14|last=Sullivan|first=Nick|archive-date=2017-12-26|archive-url=https://web.archive.org/web/20171226210134/https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet/|url-status=live}}</ref> The discovery of this intolerance also led to the prior version negotiation strategy, where the highest matching version was picked, being abandoned due to unworkable levels of ossification.<ref name=Thomson>{{ cite ietf | rfc = 9170 | title = Long-Term Viability of Protocol Extension Mechanisms | date = December 2021 | last1 = Thomson | first1 = Martin | last2 = Pauly | first2 = Tommy }}</ref> '[[Grease (networking)|Greasing]]' an extension point, where one protocol participant claims support for non-existent extensions to ensure that unrecognised-but-actually-existent extensions are tolerated and so to resist ossification, was originally designed for TLS, but it has since been adopted elsewhere.<ref name=Thomson/>

During the IETF 100 [[Hackathon]], which took place in [[Singapore]] in 2017, the TLS Group worked on adapting [[Open-source software|open-source applications]] to use TLS 1.3.<ref>{{cite web|url=https://datatracker.ietf.org/meeting/100/materials/slides-100-hackathon-sessa-tls-13|title=TLS 1.3 IETF 100 Hackathon|url-status=dead|archive-url=https://web.archive.org/web/20180115220635/https://datatracker.ietf.org/meeting/100/materials/slides-100-hackathon-sessa-tls-13|archive-date=2018-01-15}}</ref><ref name="ietf-hackathon">{{Citation|last=IETF – Internet Engineering Task Force|title=IETF Hackathon Presentations and Awards|date=2017-11-12|url=https://www.youtube.com/watch?v=33XW5yzjtME&t=2338|archive-url=https://ghostarchive.org/varchive/youtube/20211028/33XW5yzjtME|archive-date=2021-10-28|access-date=2017-11-14}}{{cbignore}}</ref> The TLS group was made up of individuals from Japan, United Kingdom, and Mauritius via the cyberstorm.mu team.<ref name="ietf-hackathon"/> This work was continued in the IETF 101 Hackathon in [[London]],<ref>{{Cite news|url=https://www.theregister.co.uk/2018/03/27/with_tls_13_signed_off_its_implementation_time|title=Hurrah! TLS 1.3 is here. Now to implement it and put it into software|access-date=2018-03-28|language=en|archive-date=2018-03-27|archive-url=https://web.archive.org/web/20180327213242/https://www.theregister.co.uk/2018/03/27/with_tls_13_signed_off_its_implementation_time/|url-status=live}}</ref> and the IETF 102 Hackathon in Montreal.<ref>{{Citation|last=IETF – Internet Engineering Task Force|title=IETF102-HACKATHON-20180715-1400|date=2018-07-15|url=https://www.youtube.com/watch?v=u6rz4PWA_As&t=4526|archive-url=https://ghostarchive.org/varchive/youtube/20211028/u6rz4PWA_As|archive-date=2021-10-28|access-date=2018-07-18}}{{cbignore}}</ref>

[[wolfSSL]] enabled the use of TLS 1.3 as of version 3.11.1, released in May 2017.<ref>{{cite web|url=https://www.wolfssl.com/wolfssl-tls-1-3-beta-release-now-available|title=wolfSSL TLS 1.3 BETA Release Now Available|date=11 May 2017|publisher=info@wolfssl.com|access-date=11 May 2017|archive-date=9 July 2018|archive-url=https://web.archive.org/web/20180709065543/https://www.wolfssl.com/wolfssl-tls-1-3-beta-release-now-available/|url-status=live}}</ref> As the first commercial TLS 1.3 implementation, wolfSSL 3.11.1 supported Draft 18 and now supports Draft 28,<ref>{{cite web|url=https://www.wolfssl.com/docs/tls13|title=TLS 1.3 PROTOCOL SUPPORT|publisher=info@wolfssl.com|access-date=2018-07-09|archive-date=2018-07-09|archive-url=https://web.archive.org/web/20180709065545/https://www.wolfssl.com/docs/tls13/|url-status=live}}</ref> the final version, as well as many older versions. A series of blogs were published on the performance difference between TLS 1.2 and 1.3.<ref>{{cite web|url=https://www.wolfssl.com/tls-1-3-draft-28-support-wolfssl|title=TLS 1.3 Draft 28 Support in wolfSSL|date=14 June 2018|publisher=info@wolfssl.com|access-date=14 June 2018|archive-date=9 July 2018|archive-url=https://web.archive.org/web/20180709065545/https://www.wolfssl.com/tls-1-3-draft-28-support-wolfssl/|url-status=live}}</ref>

In <time datetime=2018-09-11T12:00:00+00:00>September 2018</time>, the popular [[OpenSSL]] project released version 1.1.1 of its library, in which support for TLS 1.3 was "the headline new feature".<ref>{{cite web|url=https://openssl-library.org/post/2018-09-11-release111/ |title=OpenSSL 1.1.1 Is Released|date=11 Sep 2018 <!--12:00:00 GMT-->|publisher=Matt Caswell|access-date=2024-10-11|archive-date=8 December 2018|archive-url=https://web.archive.org/web/20181208141108/https://www.openssl.org/blog/blog/2018/09/11/release111/|url-status=live}}</ref>

Support for TLS 1.3 was added to [[Security Support Provider Interface|Secure Channel]] (schannel) for the {{Abbr|GA|General Availability}} releases of [[Windows 11]] and [[Windows Server 2022]].<ref>{{cite web|title=Protocols in TLS/SSL (Schannel SSP)|url=https://learn.microsoft.com/en-us/windows/win32/secauthn/protocols-in-tls-ssl--schannel-ssp-|website=Microsoft Docs|date=May 25, 2022|access-date=21 February 2023|archive-date=25 January 2023|archive-url=https://web.archive.org/web/20230125160351/https://learn.microsoft.com/en-us/windows/win32/secauthn/protocols-in-tls-ssl--schannel-ssp-|url-status=live}}</ref>

====Enterprise Transport Security====
The [[Electronic Frontier Foundation]] praised TLS 1.3 and expressed concern about the variant protocol Enterprise Transport Security (ETS) that intentionally disables important security measures in TLS 1.3.<ref name=":5">{{cite web|url=https://www.eff.org/deeplinks/2019/02/ets-isnt-tls-and-you-shouldnt-use-it|title=ETS Isn't TLS and You Shouldn't Use It|last=Hoffman-Andrews|first=Jacob|date=2019-02-26|website=[[Electronic Frontier Foundation]]|language=en|access-date=2019-02-27|archive-date=2019-02-26|archive-url=https://web.archive.org/web/20190226214559/https://www.eff.org/deeplinks/2019/02/ets-isnt-tls-and-you-shouldnt-use-it|url-status=live}}</ref> Originally called Enterprise TLS (eTLS), ETS is a published standard known as the '[[ETSI]] TS103523-3', "Middlebox Security Protocol, Part3: Enterprise Transport Security". It is intended for use entirely within proprietary networks such as banking systems. ETS does not support forward secrecy so as to allow third-party organizations connected to the proprietary networks to be able to use their private key to monitor network traffic for the detection of malware and to make it easier to conduct audits.<ref>{{cite book|title=TS 103 523-3 – V1.1.1 – CYBER; Middlebox Security Protocol; Part 3: Profile for enterprise network and data centre access control|url=https://www.etsi.org/deliver/etsi_ts/103500_103599/10352303/01.01.01_60/ts_10352303v010101p.pdf#page=5|archive-url=https://web.archive.org/web/20181114104718/https://www.etsi.org/deliver/etsi_ts/103500_103599/10352303/01.01.01_60/ts_10352303v010101p.pdf|archive-date=November 14, 2018|format=[[PDF]]|publisher=[[ETSI]].org|url-status=live}}</ref><ref>{{cite web|title=Monumental Recklessness|url=https://boingboing.net/2019/02/26/monumental-recklessness.html|date=February 26, 2019|archive-url=https://web.archive.org/web/20190227071044/http://boingboing.net/2019/02/26/monumental-recklessness.html|archive-date=February 27, 2019|website=[[Boing Boing]]|author=[[Cory Doctorow]]|url-status=live}}</ref> Despite the claimed benefits, the EFF warned that the loss of forward secrecy could make it easier for data to be exposed along with saying that there are better ways to analyze traffic.<ref name=":5" />