Editing Transport Layer Security (section)

==Applications and adoption==
In applications design, TLS is usually implemented on top of Transport Layer protocols, encrypting all of the protocol-related data of protocols such as [[Hypertext Transfer Protocol|HTTP]], [[File Transfer Protocol|FTP]], [[Simple Mail Transfer Protocol|SMTP]], [[Network News Transfer Protocol|NNTP]] and [[XMPP]].

Historically, TLS has been used primarily with reliable transport protocols such as the [[Transmission Control Protocol]] (TCP). However, it has also been implemented with datagram-oriented transport protocols, such as the [[User Datagram Protocol]] (UDP) and the [[Datagram Congestion Control Protocol]] (DCCP), usage of which has been standardized independently using the term ''[[Datagram Transport Layer Security]]'' (''DTLS'').

===Websites===
A primary use of TLS is to secure [[World Wide Web]] traffic between a [[website]] and a [[web browser]] encoded with the HTTP protocol. This use of TLS to secure HTTP traffic constitutes the [[HTTPS]] protocol.<ref>{{cite web|url=https://www.instantssl.com/ssl-certificate-products/https.html|title=Http vs https|access-date=2015-02-12|url-status=live|archive-url=https://web.archive.org/web/20150212105201/https://www.instantssl.com/ssl-certificate-products/https.html|archive-date=2015-02-12}}</ref>
{|class="wikitable"style=text-align:center
|+Website protocol support (May 2024)
|-
!scope=col|Protocol<br />version
!scope=col|Website<br />support<ref name="trustworthy_ssl_pulse">As of May 03, 2024. {{cite web|title=SSL Pulse: Survey of the SSL Implementation of the Most Popular Websites|url=https://www.ssllabs.com/ssl-pulse/|access-date=2024-05-30|website=[[Qualys]]|archive-date=2021-03-08|archive-url=https://web.archive.org/web/20210308160353/https://web.archive.org/web/20171202155646/https://www.ssllabs.com/ssl-pulse/|url-status=live}}</ref>
!scope=col|Security<ref name="trustworthy_ssl_pulse"/><ref name="community.qualys">{{cite web|url=https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what|access-date=2013-07-30|publisher=Qualsys Security Labs|author=ivanr|title=RC4 in TLS is Broken: Now What?|date=19 March 2013|url-status=live|archive-url=https://web.archive.org/web/20130827044512/https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what|archive-date=2013-08-27}}</ref>
|-
!scope=row {{Version |o |SSL 2.0}}
|0.1%
|{{Bad|Insecure}}
|-
!scope=row {{Version |o |SSL 3.0}}
|1.4%
|{{Bad|Insecure<ref name="poodle_pdf"/>}}
|-
!scope=row {{Version |o |TLS 1.0}}
|27.9%
|{{Depends|Deprecated<ref name="tls-deprecation"/><ref name=":3"/><ref name=":4"/>}}
|-
!scope=row {{Version |o |TLS 1.1}}
|30.0%
|{{Depends|Deprecated<ref name="tls-deprecation"/><ref name=":3"/><ref name=":4"/>}}
|-
!scope=row {{Version |co |TLS 1.2}}
|99.9%
|{{Depends|Depends on cipher<ref group="n"name="ciphers">see {{section link||Cipher}} table above</ref> and client mitigations<ref group="n"name="mitigations">see {{section link||Web browsers}} and {{section link||Attacks against TLS/SSL}} sections</ref>}}
|-
!scope=row {{Version |c |TLS 1.3}}
|70.1%
|{{Good|Secure}}
|}
'''Notes'''
{{reflist|group="n"}}

===Web browsers===
{{citations needed|1=section|date=April 2025}}
{{Further|topic=TLS/SSL support in web browsers|Version history for TLS/SSL support in web browsers|Comparison of web browsers}}
{{As of|2025|03}}, the latest versions of all major web browsers support TLS 1.2 and 1.3 and have them enabled by default, with the exception of [[Internet_Explorer_11|IE 11]]. TLS 1.0 and 1.1 are disabled by default on the latest versions of all major browsers.

Mitigations against known attacks are not enough yet:
*Mitigations against [[#POODLE attack|POODLE attack]]: some browsers already prevent fallback to SSL 3.0; however, this mitigation needs to be supported by not only clients but also servers. Disabling SSL 3.0 itself, implementation of "anti-POODLE record splitting", or denying CBC ciphers in SSL 3.0 is required.
**Google Chrome: complete (TLS_FALLBACK_SCSV is implemented since version 33, fallback to SSL 3.0 is disabled since version 39, SSL 3.0 itself is disabled by default since version 40. Support of SSL 3.0 itself was dropped since version 44.)
**Mozilla Firefox: complete (support of SSL 3.0 itself is dropped since [[History of Firefox#Version 38–44|version 39]]. SSL 3.0 itself is disabled by default and fallback to SSL 3.0 are disabled since [[History of Firefox#Version 31–37|version 34]], TLS_FALLBACK_SCSV is implemented since version 35. In ESR, SSL 3.0 itself is disabled by default and TLS_FALLBACK_SCSV is implemented since ESR 31.3.0.)
**Internet Explorer: partial (only in version 11, SSL 3.0 is disabled by default since April 2015. Version 10 and older are still vulnerable against POODLE.)
**[[Opera (web browser)|Opera]]: complete (TLS_FALLBACK_SCSV is implemented since version 20, "anti-POODLE record splitting", which is effective only with client-side implementation, is implemented since version 25, SSL 3.0 itself is disabled by default since version 27. Support of SSL 3.0 itself will be dropped since version 31.)
**Safari: complete (only on OS X 10.8 and later and iOS 8, CBC ciphers during fallback to SSL 3.0 is denied, but this means it will use RC4, which is not recommended as well. Support of SSL 3.0 itself is dropped on OS X 10.11 and later and iOS 9.)
*Mitigation against [[#RC4 attacks|RC4 attacks]]:
**Google Chrome disabled RC4 except as a fallback since version 43. RC4 is disabled since Chrome 48.
**Firefox disabled RC4 except as a fallback since version 36. Firefox 44 disabled RC4 by default.
**Opera disabled RC4 except as a fallback since version 30. RC4 is disabled since Opera 35.
**Internet Explorer for [[Windows 7]]/Server 2008 R2 and for [[Windows 8]]/Server 2012 have set the priority of RC4 to lowest and can also disable RC4 except as a fallback through registry settings. Internet Explorer 11 Mobile 11 for [[Windows Phone 8.1]] disable RC4 except as a fallback if no other enabled algorithm works. Edge [Legacy] and IE 11 disable RC4 completely in August 2016.
*Mitigation against [[#FREAK|FREAK attack]]:
**The Android Browser included with [[Android Ice Cream Sandwich|Android 4.0]] and older is still vulnerable to the FREAK attack.
**Internet Explorer 11 Mobile is still vulnerable to the FREAK attack.
**Google Chrome, Internet Explorer (desktop), Safari (desktop & mobile), and Opera (mobile) have FREAK mitigations in place.
**Mozilla Firefox on all platforms and Google Chrome on Windows were not affected by FREAK.

===Libraries===
{{Main|Comparison of TLS implementations}}{{Further|topic=protocol version support in libraries|Comparison of TLS implementations#TLS version support}}
Most SSL and TLS programming libraries are [[free and open-source software]].
*[[BoringSSL]], a fork of OpenSSL for Chrome/Chromium and Android as well as other Google applications.
*[[Botan (programming library)|Botan]], a BSD-licensed cryptographic library written in C++.
*[[BSAFE]] Micro Edition Suite: a multi-platform implementation of TLS written in [[C (programming language)|C]] using a FIPS-validated cryptographic module
*[[BSAFE]] SSL-J: a TLS library providing both a proprietary API and [[Java Secure Socket Extension|JSSE]] API, using FIPS-validated cryptographic module
*[[cryptlib]]: a portable open source cryptography library (includes TLS/SSL implementation)
*[[Delphi (programming language)|Delphi]] programmers may use a library called Indy which utilizes [[OpenSSL]] or alternatively ICS which supports TLS 1.3 now.
*[[GnuTLS]]: a free implementation (LGPL licensed)
*[[Java Secure Socket Extension]] (JSSE): the [[Java (programming language)|Java]] API and provider implementation (named SunJSSE)<ref>{{cite web|title=Java Secure Socket Extension (JSSE) Reference Guide|url=https://docs.oracle.com/en/java/javase/17/security/java-secure-socket-extension-jsse-reference-guide.html|access-date=2021-12-24|website=Oracle Help Center|language=en-US|archive-date=2022-01-22|archive-url=https://web.archive.org/web/20220122070356/https://docs.oracle.com/en/java/javase/17/security/java-secure-socket-extension-jsse-reference-guide.html|url-status=live}}</ref>
*[[LibreSSL]]: a fork of OpenSSL by OpenBSD project.
*[[MatrixSSL]]: a dual licensed implementation
*[[Mbed TLS]] (previously PolarSSL): A tiny SSL library implementation for embedded devices that is designed for ease of use
*[[Network Security Services]]: [[FIPS 140]] validated open source library
*[[OpenSSL]]: a free implementation (BSD license with some extensions)
*[[Security Support Provider Interface|Schannel]]: an implementation of SSL and TLS [[Microsoft Windows]] as part of its package.
*[[Secure Transport]]: an implementation of SSL and TLS used in [[OS X]] and [[iOS]] as part of their packages.
*[[wolfSSL]] (previously CyaSSL): Embedded SSL/TLS Library with a strong focus on speed and size.

A paper presented at the 2012 [[Association for Computing Machinery|ACM]] [[computer security conference|conference on computer and communications security]]<ref>{{cite book|last1=Georgiev|first1=Martin|last2=Iyengar|first2=Subodh|last3=Jana|first3=Suman|last4=Anubhai|first4=Rishita|last5=Boneh|first5=Dan|last6=Shmatikov|first6=Vitaly|title=The most dangerous code in the world: validating SSL certificates in non-browser software. Proceedings of the 2012 ACM conference on Computer and communications security|year=2012|isbn=978-1-4503-1651-4|url=http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf|pages=38–49|publisher=Association for Computing Machinery |url-status=live|archive-url=https://web.archive.org/web/20171022194807/http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf|archive-date=2017-10-22}}</ref> showed that many applications used some of these SSL libraries incorrectly, leading to vulnerabilities. According to the authors:
<blockquote>"The root cause of most of these vulnerabilities is the terrible design of the APIs to the underlying SSL libraries. Instead of expressing high-level security properties of network tunnels such as confidentiality and authentication, these APIs expose low-level details of the SSL protocol to application developers. As a consequence, developers often use SSL APIs incorrectly, misinterpreting and misunderstanding their manifold parameters, options, side effects, and return values."</blockquote>

===Other uses===
The [[Simple Mail Transfer Protocol]] (SMTP) can also be protected by TLS. These applications use [[public key certificate]]s to verify the identity of endpoints.

TLS can also be used for tunneling an entire network stack to create a [[virtual private network|VPN]], which is the case with [[OpenVPN]] and [[OpenConnect]]. Many vendors have by now married TLS's encryption and authentication capabilities with authorization. There has also been substantial development since the late 1990s in creating client technology outside of Web-browsers, in order to enable support for client/server applications. Compared to traditional [[IPsec]] VPN technologies, TLS has some inherent advantages in firewall and [[network address translation|NAT]] traversal that make it easier to administer for large remote-access populations.

TLS is also a standard method for protecting [[Session Initiation Protocol]] (SIP) application signaling. TLS can be used for providing authentication and encryption of the SIP signaling associated with [[Voice over IP|VoIP]] and other SIP-based applications.<ref>{{cite IETF|rfc=5630|title=The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)|year=2009 |doi=10.17487/RFC5630 |last1=Audet |first1=F. }}</ref>