Editing Transport Layer Security (section)

==History and development==
{|class="wikitable sortable"style=float:right;text-align:center;margin-left:1em
|+SSL and TLS protocols
|-
!scope=col|Protocol
!scope=col|Published
!scope=col|Status
|-
|scope=row {{Version |o |SSL 1.0}}
|{{N/A|Unpublished}}
|{{N/A|Unpublished}}
|-
|scope=row {{Version |o |SSL 2.0}}
|1995
|Deprecated in 2011 ({{IETF RFC|6176|link=no}})
|-
|scope=row {{Version |o |SSL 3.0}}
|1996
|Deprecated in 2015 ({{IETF RFC|7568|link=no}})
|-
|scope=row {{Version |o |TLS 1.0}}
|1999
|Deprecated in 2021 ({{IETF RFC|8996|link=no}})<ref name="tls-deprecation"/><ref name=":3">{{cite web|url=https://www.ghacks.net/2020/03/10/here-is-what-is-new-and-changed-in-firefox-74-0-stable|title=Here is what is new and changed in Firefox 74.0 Stable – gHacks Tech News|website=www.ghacks.net|date=10 March 2020|access-date=2020-03-10|archive-date=2020-03-11|archive-url=https://web.archive.org/web/20200311120434/https://www.ghacks.net/2020/03/10/here-is-what-is-new-and-changed-in-firefox-74-0-stable/|url-status=live}}</ref><ref name=":4">{{cite web|url=https://chromestatus.com/feature/5759116003770368|title=TLS 1.0 and TLS 1.1 – Chrome Platform Status|website=chromestatus.com|access-date=2020-03-10|archive-date=2023-07-07|archive-url=https://web.archive.org/web/20230707094450/https://chromestatus.com/feature/5759116003770368|url-status=live}}</ref>
|-
|scope=row {{Version |o |TLS 1.1}}
|2006
|Deprecated in 2021 ({{IETF RFC|8996|link=no}})<ref name="tls-deprecation"/><ref name=":3"/><ref name=":4"/>
|-
|scope=row {{Version |co |TLS 1.2}}
|2008
|In use since 2008{{Ref RFC|5246}}<ref name="ncsc">{{cite web|title=Using TLS to protect data|url=https://www.ncsc.gov.uk/guidance/using-tls-to-protect-data|archive-url=https://web.archive.org/web/20210721072543/http://ncsc.gov.uk/guidance/using-tls-to-protect-data|archive-date=July 21, 2021|access-date=August 24, 2022|website=www.ncsc.gov.uk|url-status=live}}</ref>
|-
|scope=row {{Version |c |TLS 1.3}}
|2018
|In use since 2018<ref name="ncsc"/><ref>{{cite web|title=TLS 1.3: One Year Later|url=https://www.ietf.org/blog/tls13-adoption|archive-url=https://web.archive.org/web/20200708030455/https://www.ietf.org/blog/tls13-adoption|archive-date=July 8, 2020|access-date=August 24, 2022|website=IETF|url-status=live}}</ref>
|-
|colspan="3" | {{Version|l|show=011100}}
|}

===Early research projects===

====Secure Data Network System====
{{Anchor|DNS}}
In August 1986, the National Security Agency, the National Bureau of Standards, the Defense Communications Agency launched a project, called the Secure Data Network System (SDNS), with the intent of designing the next generation of secure computer communications network and product specifications to be implemented for applications on public and private internets. It was intended to complement the rapidly emerging new OSI internet standards moving forward both in the U.S. government's GOSIP Profiles and in the huge ITU-ISO JTC1 internet effort internationally.<ref>{{cite web|url=https://www.circleid.com/posts/20190124_creating_tls_the_pioneering_role_of_ruth_nelson|title=Creating TLS: The Pioneering Role of Ruth Nelson|access-date=2020-07-04|archive-date=2020-06-24|archive-url=https://web.archive.org/web/20200624123447/http://www.circleid.com/posts/20190124_creating_tls_the_pioneering_role_of_ruth_nelson/|url-status=live}}</ref>

As part of the project, researchers designed a protocol called SP4 (''security protocol'' in layer 4 of the OSI system). This was later renamed the Transport Layer Security Protocol (TLSP) and subsequently published in 1995 as international standard ITU-T X.274|ISO/IEC 10736:1995.<ref>{{cite web|url=https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.274-199407-I!!PDF-E&type=items|title=Information technology – Telecommunication and information exchange between systems – Transport layer security protocol|access-date=2025-05-03|archive-date=2025-05-03|archive-url=https://web.archive.org/web/20250503170309/https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.274-199407-I!!PDF-E&type=items|url-status=live}}</ref> Despite the name similarity, this is distinct from today's TLS.

===={{Anchor|SNP}}Secure Network Programming (SNP)====
Other efforts towards transport layer security included the [[Secure Network Programming]] (SNP) [[application programming interface]] (API), which in 1993 explored the approach of having a secure transport layer API closely resembling [[Berkeley sockets]], to facilitate retrofitting pre-existing network applications with security measures. SNP was published and presented in the 1994 [[USENIX]] Summer Technical Conference.<ref name="Woo94">{{cite conference |first1=Thomas Y. C. |last1=Woo |first2=Raghuram |last2=Bindignavle |first3=Shaowen |last3=Su |first4=Simon S. |last4=Lam |author-link4=Simon S. Lam |url=http://www.cs.utexas.edu/users/lam/Vita/Cpapers/WBSL94.pdf |title=SNP: An interface for secure network programming |conference=Proceedings USENIX Summer Technical Conference |date=June 1994 |access-date=2023-07-05 |archive-date=2014-12-12 |archive-url=https://web.archive.org/web/20141212000043/http://www.cs.utexas.edu/users/lam/Vita/Cpapers/WBSL94.pdf |url-status=live }}</ref><ref>{{cite web |url=https://www.usenix.org/legacy/publications/library/proceedings/bos94/ |title=1994 USENIX Summer Technical Conference Program, Boston, 6–10 June 1994 |access-date=21 January 2024 |archive-date=6 October 2023 |archive-url=https://web.archive.org/web/20231006204601/https://www.usenix.org/legacy/publications/library/proceedings/bos94/ |url-status=live }}</ref> The SNP project was funded by a grant from [[National Security Agency|NSA]] to Professor [[Simon Lam]] at [[University of Texas at Austin|UT-Austin]] in 1991.<ref>[[Simon S. Lam]] (PI/PD), "Applying a Theory of Modules and Interfaces to Security Verification," NSA INFOSEC University Research Program grant no. MDA 904-91-C-7046, 6/28/91 to 6/27/93.</ref> [[Secure Network Programming]] won the 2004 [[ACM Software System Award]].<ref>{{cite web|url=https://awards.acm.org/award_winners/lam_1287606.cfm|title=2004 ACM Software System Award citation|publisher=[[Association for Computing Machinery|ACM]]|access-date=25 July 2012|archive-date=17 June 2013|archive-url=https://web.archive.org/web/20130617014921/http://awards.acm.org/award_winners/lam_1287606.cfm|url-status=live}}</ref><ref>{{cite web|url=https://www.cs.utexas.edu/~lam/Awards/SoftwareSystemAward/ACM%20Press%20Release,%20March%2015,%202005.htm|title=ACM Press Release, March 15, 2005|publisher=[[Association for Computing Machinery|ACM]]|access-date=25 July 2012|archive-date=10 January 2016|archive-url=https://web.archive.org/web/20160110063723/http://www.cs.utexas.edu/~lam/Awards/SoftwareSystemAward/ACM%20Press%20Release,%20March%2015,%202005.htm|url-status=live}}</ref>  Simon Lam was inducted into the [[Internet Hall of Fame]] for "inventing secure sockets and implementing the first secure sockets layer, named SNP, in 1993."<ref>{{cite web| url=https://www.internethalloffame.org/inductee/simon-s-lam| title=Internet Hall of Fame inductee Simon S. Lam| access-date=3 Mar 2024| archive-date=6 February 2024| archive-url=https://web.archive.org/web/20240206211215/https://www.internethalloffame.org/inductee/simon-s-lam/| url-status=live}}</ref><ref>{{cite web|url=https://cns.utexas.edu/news/accolades/computer-scientist-inducted-internet-hall-fame|title=Computer Scientist Inducted into Internet Hall of Fame|access-date=3 Mar 2024|archive-date=8 March 2024|archive-url=https://web.archive.org/web/20240308192655/https://cns.utexas.edu/news/accolades/computer-scientist-inducted-internet-hall-fame|url-status=live}}</ref>

===SSL 1.0, 2.0, and 3.0===
{{redirect|SSL 1|the enzyme|Presqualene diphosphate synthase}}
Netscape developed the original SSL protocols, and [[Taher Elgamal]], chief scientist at [[Netscape|Netscape Communications]] from 1995 to 1998, has been described as the "father of SSL".<ref name="Messmer">{{cite news|last=Messmer|first=Ellen|title=Father of SSL, Dr. Taher Elgamal, Finds Fast-Moving IT Projects in the Middle East|url=http://www.networkworld.com/news/2012/120412-elgamal-264739.html|work=Network World|access-date=30 May 2014|url-status=dead|archive-url=https://web.archive.org/web/20140531105537/http://www.networkworld.com/news/2012/120412-elgamal-264739.html|archive-date=31 May 2014}}</ref><ref name="Greene">{{cite news|last=Greene|first=Tim|title=Father of SSL says despite attacks, the security linchpin has lots of life left|url=http://www.networkworld.com/news/2011/101111-elgamal-251806.html|work=Network World|access-date=30 May 2014|url-status=dead|archive-url=https://web.archive.org/web/20140531105257/http://www.networkworld.com/news/2011/101111-elgamal-251806.html|archive-date=31 May 2014}}</ref><ref name=Oppliger>{{cite book|title=SSL and TLS: Theory and Practice|edition=2nd|last=Oppliger|first=Rolf|year=2016|chapter=Introduction|chapter-url=https://books.google.com/books?id=jm6uDgAAQBAJ&pg=PA15|page=13|publisher=[[Artech House]]|isbn=978-1-60807-999-5|via=Google Books|access-date=2018-03-01}}</ref><ref>{{cite web|archive-url=https://web.archive.org/web/19970614020952/http://home.netscape.com/newsref/std/SSL.html|archive-date=14 June 1997|title=THE SSL PROTOCOL|url=http://home.netscape.com/newsref/std/SSL.html|publisher=Netscape Corporation|year=2007}}</ref> SSL version 1.0 was never publicly released because of serious security flaws in the protocol. Version 2.0, after being released in February 1995 was quickly found to contain a number of security and usability flaws. It used the same cryptographic keys for message authentication and encryption. It had a weak MAC construction that used the MD5 hash function with a secret prefix, making it vulnerable to length extension attacks. It also provided no protection for either the opening handshake or an explicit message close, both of which meant [[man-in-the-middle attacks]] could go undetected. Moreover, SSL 2.0 assumed a single service and a fixed domain certificate, conflicting with the widely used feature of virtual hosting in Web servers, so most websites were effectively impaired from using SSL.

These flaws necessitated the complete redesign of the protocol to SSL version 3.0.<ref>{{harvnb|Rescorla|2001}}</ref><ref name=Oppliger/> Released in 1996, it was produced by [[Paul Carl Kocher|Paul Kocher]] working with Netscape engineers Phil Karlton and Alan Freier, with a reference implementation by Christopher Allen and Tim Dierks of Certicom. Newer versions of SSL/TLS are based on SSL 3.0. The 1996 draft of SSL 3.0 was published by IETF as a historical document in {{IETF RFC|6101}}.

SSL 2.0 was deprecated in 2011 by {{IETF RFC|6176}}. In 2014, SSL 3.0 was found to be vulnerable to the [[POODLE]] attack that affects all [[block cipher]]s in SSL; [[RC4]], the only non-block cipher supported by SSL 3.0, is also feasibly broken as used in SSL 3.0.<ref name="Poodle">{{cite web|url=https://access.redhat.com/articles/1232123|title=POODLE: SSLv3 vulnerability (CVE-2014-3566)|access-date=21 October 2014|url-status=live|archive-url=https://web.archive.org/web/20141205124712/https://access.redhat.com/articles/1232123|archive-date=5 December 2014}}</ref> SSL 3.0 was deprecated in June 2015 by {{IETF RFC|7568}}.

===TLS 1.0===
TLS 1.0 was first defined in {{IETF RFC|2246}} in January 1999 as an upgrade of SSL Version 3.0, and written by Christopher Allen and Tim Dierks of Certicom. As stated in the RFC, "the differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough to preclude interoperability between TLS 1.0 and SSL 3.0". Tim Dierks later wrote that these changes, and the renaming from "SSL" to "TLS", were a face-saving gesture to Microsoft, "so it wouldn't look [like] the IETF was just rubberstamping Netscape's protocol".<ref>{{cite web|url=http://tim.dierks.org/2014/05/security-standards-and-name-changes-in.html|title=Security Standards and Name Changes in the Browser Wars|access-date=2020-02-29|archive-date=2020-02-29|archive-url=https://web.archive.org/web/20200229221707/http://tim.dierks.org/2014/05/security-standards-and-name-changes-in.html|url-status=live}}</ref>

The [[Payment Card Industry Security Standards Council|PCI Council]] suggested that organizations migrate from TLS 1.0 to TLS 1.1 or higher before June 30, 2018.<ref>{{cite web|url=https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls|title=Date Change for Migrating from SSL and Early TLS|author=Laura K. Gray|date=2015-12-18|website=[[Payment Card Industry Security Standards Council]] blog|access-date=2018-04-05|archive-date=2015-12-20|archive-url=https://web.archive.org/web/20151220190802/http://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls|url-status=live}}</ref><ref>{{Cite news|url=https://www.forbes.com/sites/thesba/2018/05/30/changes-to-pci-compliance-are-coming-june-30-is-your-ecommerce-business-ready|title=Changes to PCI Compliance are Coming June 30. Is Your Ecommerce Business Ready?|work=Forbes|access-date=2018-06-20|language=en|archive-date=2018-06-21|archive-url=https://web.archive.org/web/20180621020422/https://www.forbes.com/sites/thesba/2018/05/30/changes-to-pci-compliance-are-coming-june-30-is-your-ecommerce-business-ready/|url-status=live}}</ref> In October 2018, [[Apple Inc.|Apple]], [[Google]], [[Microsoft]], and [[Mozilla]] jointly announced they would deprecate TLS 1.0 and 1.1 in March 2020.<ref name="tls-deprecation">{{cite web|url=https://arstechnica.com/gadgets/2018/10/browser-vendors-unite-to-end-support-for-20-year-old-tls-1-0|title=Apple, Google, Microsoft, and Mozilla come together to end TLS 1.0|last=Bright|first=Peter|date=17 October 2018|access-date=17 October 2018|archive-date=17 October 2018|archive-url=https://web.archive.org/web/20181017000107/https://arstechnica.com/gadgets/2018/10/browser-vendors-unite-to-end-support-for-20-year-old-tls-1-0/|url-status=live}}</ref> TLS 1.0 and 1.1 were formally deprecated in {{IETF RFC|8996}} in March 2021.

===TLS 1.1===
TLS 1.1 was defined in RFC 4346 in April 2006.{{Ref RFC|4346}} It is an update from TLS version 1.0. Significant differences in this version include:
*Added protection against [[Block cipher mode of operation#Cipher Block Chaining (CBC)|cipher-block chaining]] (CBC) attacks.
**The implicit [[initialization vector]] (IV) was replaced with an explicit IV.
**Change in handling of [[Block cipher mode of operation#Padding|padding errors]].
*Support for [[Internet Assigned Numbers Authority|IANA]] registration of parameters.<ref name="urlnvlpubs.nist.gov">{{Cite web |title=Transport Layer Security Parameters – Cipher Suites |url=https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 |access-date=2022-12-16 |website=Internet Assigned Numbers Authority (IANA) |archive-date=2016-12-21 |archive-url=https://web.archive.org/web/20161221223613/http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 |url-status=live }}</ref>
Support for TLS versions 1.0 and 1.1 was widely deprecated by web sites around 2020,<ref>{{cite web|last1=Mackie|first1=Kurt|title=Microsoft Delays End of Support for TLS 1.0 and 1.1 -|url=https://mcpmag.com/articles/2020/04/02/microsoft-tls-1-0-and-1-1.aspx|website=Microsoft Certified Professional Magazine Online|access-date=2021-06-14|archive-date=2021-06-14|archive-url=https://web.archive.org/web/20210614004948/https://mcpmag.com/articles/2020/04/02/microsoft-tls-1-0-and-1-1.aspx|url-status=live}}</ref> disabling access to [[Firefox]] versions before 24 and [[Chromium (web browser)|Chromium-based browsers]] before 29,<ref>{{Cite web|url=https://answers.psionline.com/knowledgebase/tls-1-2-faq|title=TLS 1.2 FAQ – Knowledge Base|website=Answers.psionline.com|access-date=20 February 2022|archive-date=20 February 2022|archive-url=https://web.archive.org/web/20220220051112/https://answers.psionline.com/knowledgebase/tls-1-2-faq/|url-status=dead}}</ref> though third-party fixes can be applied to Netscape Navigator and older versions of Firefox to add TLS 1.2 support.<ref>{{cite web|title=Using Netscape 9 in 2022|url=https://msfn.org/board/topic/183515-using-netscape-9-in-2022|website=MSFN|access-date=2025-04-24|archive-date=2025-04-18|archive-url=https://web.archive.org/web/20250418030114/https://msfn.org/board/topic/183515-using-netscape-9-in-2022/|url-status=live}}</ref>

===TLS 1.2===
TLS 1.2 was defined in {{IETF RFC|5246}} in August 2008.{{Ref RFC|5246}} It is based on the earlier TLS 1.1 specification. Major differences include:
*The [[MD5]] and [[SHA-1]] combination in the [[Pseudorandom function family|pseudorandom function]] (PRF) was replaced with [[SHA-256]], with an option to use [[cipher suite]] specified PRFs.
*The MD5 and SHA-1 combination in the finished message [[Hash function|hash]] was replaced with SHA-256, with an option to use cipher suite specific hash algorithms. However, the size of the hash in the finished message must still be at least 96 [[bit]]s.{{Ref RFC|5246|rsection=7.4.9}}
*The MD5 and SHA-1 combination in the digitally signed element was replaced with a single hash negotiated during [[Handshake (computing)|handshake]], which defaults to SHA-1.
*Enhancement in the client's and server's ability to specify which hashes and signature algorithms they accept.
*Expansion of support for [[authenticated encryption]] ciphers, used mainly for [[Galois/Counter Mode]] (GCM) and [[CCM mode]] of [[Advanced Encryption Standard]] (AES) encryption.
*TLS Extensions definition and AES cipher suites were added.<ref name="urlnvlpubs.nist.gov" />

All TLS versions were further refined in {{IETF RFC|6176}} in March 2011, removing their backward compatibility with SSL such that TLS sessions never negotiate the use of Secure Sockets Layer (SSL) version 2.0. As of April 2025 there is no formal date for TLS 1.2 to be deprecated. The specifications for TLS 1.2 became redefined as well by the Standards Track Document {{IETF RFC|8446}} to keep it as secure as possible; it is to be seen as a failover protocol now, meant only to be negotiated with clients which are unable to talk over TLS 1.3 (The original RFC 5246 definition for TLS 1.2 is since then obsolete).

===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" />