Editing Transport Layer Security (section)

==Algorithms==
{{see also|Cipher suite}}

===Key exchange or key agreement===
Before a client and server can begin to exchange information protected by TLS, they must securely exchange or agree upon an encryption key and a cipher to use when encrypting data (see {{section link||Cipher}}). Among the methods used for key exchange/agreement are: public and private keys generated with [[RSA (algorithm)|RSA]] (denoted TLS_RSA in the TLS handshake protocol), [[Diffie–Hellman]] (TLS_DH), ephemeral Diffie–Hellman (TLS_DHE), [[elliptic-curve Diffie–Hellman]] (TLS_ECDH), ephemeral elliptic-curve Diffie–Hellman (TLS_ECDHE), [[Key-agreement protocol#Exponential key exchange|anonymous Diffie–Hellman]] (TLS_DH_anon),{{Ref RFC|5246}} [[TLS-PSK|pre-shared key]] (TLS_PSK)<ref name=RFC4279>{{cite IETF|title=Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)|rfc=4279|publisher=Internet Engineering Task Force|access-date=9 September 2013|author=P. Eronen, Ed.|editor-first1=P |editor-first2=H |editor-last1=Eronen |editor-last2=Tschofenig |date=December 2005}}</ref> and [[TLS-SRP|Secure Remote Password]] (TLS_SRP).<ref name=RFC5054>{{cite IETF|rfc=5054|title=Using the Secure Remote Password (SRP) Protocol for TLS Authentication|publisher=Internet Engineering Task Force|access-date=December 21, 2014|author=D. Taylor, Ed.|date=November 2007}}</ref>

The TLS_DH_anon and TLS_ECDH_anon key agreement methods do not authenticate the server or the user and hence are rarely used because those are vulnerable to [[man-in-the-middle attack]]s. Only TLS_DHE and TLS_ECDHE provide [[#Forward secrecy|forward secrecy]].

Public key certificates used during exchange/agreement also vary in the size of the public/private encryption keys used during the exchange and hence the robustness of the security provided. In July 2013, [[Google]] announced that it would no longer use 1024-bit public keys and would switch instead to 2048-bit keys to increase the security of the TLS encryption it provides to its users because the encryption strength is directly related to the [[key size]].<ref>{{cite web|last=Gothard|first=Peter|title=Google updates SSL certificates to 2048-bit encryption|url=http://www.computing.co.uk/ctg/news/2285984/google-updates-ssl-certificates-to-2048bit-encryption|work=Computing|date=31 July 2013|publisher=Incisive Media|access-date=9 September 2013|url-status=live|archive-url=https://web.archive.org/web/20130922082322/http://www.computing.co.uk/ctg/news/2285984/google-updates-ssl-certificates-to-2048bit-encryption|archive-date=22 September 2013}}</ref><ref>{{Cite news|url=http://searchsecurity.techtarget.com/answer/From-1024-to-2048-bit-The-security-effect-of-encryption-key-length|title=The value of 2,048-bit encryption: Why encryption key length matters|work=SearchSecurity|access-date=2017-12-18|language=en-US|url-status=live|archive-url=https://web.archive.org/web/20180116081141/http://searchsecurity.techtarget.com/answer/From-1024-to-2048-bit-The-security-effect-of-encryption-key-length|archive-date=2018-01-16}}</ref>

{{anchor|keyexchange-table}}
{{sticky header}}
{|class="wikitable sticky-header"style=text-align:center
|+Key exchange/agreement and authentication
!scope=col|Algorithm
!scope=col|SSL 2.0
!scope=col|SSL 3.0
!scope=col|TLS 1.0
!scope=col|TLS 1.1
!scope=col|TLS 1.2
!scope=col|TLS 1.3
!scope=col|Status
|-
!{{Depends|[[RSA (cryptosystem)|RSA]]}}
|{{Yes}}||{{Yes}}||{{Yes}}||{{Yes}}||{{Yes}}||{{N/A|No}}||rowspan=21|Defined for TLS 1.2 in RFCs
|-
!{{Depends|[[Diffie–Hellman key exchange|DH]]-[[RSA (cryptosystem)|RSA]]}}
|{{No}}||{{Yes}}||{{Yes}}||{{Yes}}||{{Yes}}||{{N/A|No}}
|-
!{{Good|[[Diffie–Hellman key exchange|DHE]]-[[RSA (cryptosystem)|RSA]] ([[#Forward secrecy|forward secrecy]])}}
|{{No}}||{{Yes}}||{{Yes}}||{{Yes}}||{{Yes}}||{{Yes}}
|-
!{{Depends|[[Elliptic-curve Diffie–Hellman|ECDH]]-[[RSA (cryptosystem)|RSA]]}}
|{{No}}||{{No}}||{{Yes}}||{{Yes}}||{{Yes}}||{{N/A|No}}
|-
!{{Good|[[Elliptic-curve Diffie–Hellman|ECDHE]]-[[RSA (cryptosystem)|RSA]] (forward secrecy)}}
|{{No}}||{{No}}||{{Yes}}||{{Yes}}||{{Yes}}||{{Yes}}
|-
!{{Depends|[[Diffie–Hellman key exchange|DH]]-[[Digital Signature Algorithm|DSS]]}}
|{{No}}||{{Yes}}||{{Yes}}||{{Yes}}||{{Yes}}||{{N/A|No}}
|-
!{{Good|[[Diffie–Hellman key exchange|DHE]]-[[Digital Signature Algorithm|DSS]] (forward secrecy)}}
|{{No}}||{{Yes}}||{{Yes}}||{{Yes}}||{{Yes}}||{{N/A|No}}<ref>{{cite web|url=https://www.ietf.org/mail-archive/web/tls/current/msg17680.html|title=Consensus: remove DSA from TLS 1.3|date=September 17, 2015|author=Sean Turner|url-status=live|archive-url=https://web.archive.org/web/20151003193113/http://www.ietf.org/mail-archive/web/tls/current/msg17680.html|archive-date=October 3, 2015}}</ref>
|-
!{{Good|[[Diffie–Hellman key exchange|DHE]]-[[Elliptic Curve DSA|ECDSA]] (forward secrecy)}}
|{{N/A|No}}||{{N/A|No}}||{{N/A|No}}||{{N/A|No}}||{{N/A|No}}||{{Yes}}
|-
!{{Depends|[[Elliptic-curve Diffie–Hellman|ECDH]]-[[Elliptic Curve DSA|ECDSA]]}}
|{{No}}||{{No}}||{{Yes}}||{{Yes}}||{{Yes}}||{{N/A|No}}
|-
!{{Good|[[Elliptic-curve Diffie–Hellman|ECDHE]]-[[Elliptic Curve DSA|ECDSA]] (forward secrecy)}}
|{{No}}||{{No}}||{{Yes}}||{{Yes}}||{{Yes}}||{{Yes}}
|-
!{{Good|[[Diffie–Hellman key exchange|DHE]]-[[EdDSA]] (forward secrecy)}}
|{{N/A|No}}||{{N/A|No}}||{{N/A|No}}||{{N/A|No}}||{{N/A|No}}||{{Yes}}
|-
!{{Depends|[[Elliptic-curve Diffie–Hellman|ECDH]]-[[EdDSA]]}}
|{{No}}
|{{No}}
|{{Yes}}
|{{Yes}}
|{{Yes}}
|{{N/A|No}}
|-
!{{Good|[[Elliptic-curve Diffie–Hellman|ECDHE]]-[[EdDSA]] (forward secrecy)}}<ref>{{IETF RFC|8422}}</ref>
|{{No}}
|{{No}}
|{{Yes}}
|{{Yes}}
|{{Yes}}
|{{Yes}}
|-
!{{Depends|[[TLS-PSK|PSK]]}}
|{{No}}||{{No}}||{{Yes}}||{{Yes}}||{{Yes}}||{{Yes}}
|-
!{{Depends|[[RSA (cryptosystem)|RSA]]-[[Pre-shared key|PSK]]}}
|{{No}}||{{No}}||{{Yes}}||{{Yes}}||{{Yes}}||{{N/A|No}}
|-
!{{Good|[[Diffie–Hellman key exchange|DHE]]-[[Pre-shared key|PSK]] (forward secrecy)}}
|{{No}}||{{No}}||{{Yes}}||{{Yes}}||{{Yes}}||{{Yes}}
|-
!{{Good|[[Elliptic-curve Diffie–Hellman|ECDHE]]-[[Pre-shared key|PSK]] (forward secrecy)}}
|{{No}}||{{No}}||{{Yes}}||{{Yes}}||{{Yes}}||{{Yes}}
|-
!{{Depends|[[TLS-SRP|SRP]]}}
|{{No}}||{{No}}||{{Yes}}||{{Yes}}||{{Yes}}||{{N/A|No}}
|-
!{{Depends|[[Secure Remote Password protocol|SRP]]-[[Digital Signature Algorithm|DSS]]}}
|{{No}}||{{No}}||{{Yes}}||{{Yes}}||{{Yes}}||{{N/A|No}}
|-
!{{Depends|[[Secure Remote Password protocol|SRP]]-[[RSA (cryptosystem)|RSA]]}}
|{{No}}||{{No}}||{{Yes}}||{{Yes}}||{{Yes}}||{{N/A|No}}
|-
!{{Depends|[[Kerberos (protocol)|Kerberos]]}}
|{{No}}||{{No}}||{{Yes}}||{{Yes}}||{{Yes}}||{{dunno}}
|-
!{{Bad|[[Diffie–Hellman key exchange|DH]]-ANON (insecure)}}
|{{N/A|No}}||{{No|Yes}}||{{No|Yes}}||{{No|Yes}}||{{No|Yes}}||{{N/A|No}}
|-
!{{Bad|[[Elliptic-curve Diffie–Hellman|ECDH]]-ANON (insecure)}}
|{{N/A|No}}||{{N/A|No}}||{{No|Yes}}||{{No|Yes}}||{{No|Yes}}||{{N/A|No}}
|-
!{{Good|[[GOST|GOST R 34.10-2012]]<ref name=gostlink>{{IETF RFC|5830|6986|7091|7801|8891}}</ref>}}
|{{No}}||{{No}}||{{No}}||{{No}}||{{Yes}}||{{Yes}}
|Defined for TLS 1.2 and for TLS 1.3 in {{IETF RFC|9189|9367}}.
|}

===Cipher===
{{see also|Cipher suite|Block cipher|Cipher security summary}}
{{Anchor|cipher-table}}
{{sticky header}}
{{sort under}}
{|class="wikitable sortable sticky-header-multi sort-under" style=text-align:center
|+[[Cipher]] security against publicly known feasible attacks
|-
!colspan=3|Cipher!!colspan=6|Protocol version!!rowspan=2|Status
|-
!Type
!Algorithm
!Nominal strength (bits)
!SSL 2.0
!SSL 3.0<br/><ref group="n"name="rfc5746">{{IETF RFC|5746}} must be implemented to fix a renegotiation flaw that would otherwise break this protocol.</ref><ref group="n"name="renegotiation">If libraries implement fixes listed in {{IETF RFC|5746}}, this violates the SSL 3.0 specification, which the IETF cannot change unlike TLS. Most current libraries implement the fix and disregard the violation that this causes.</ref><ref group="n"name="BEAST">The [[#BEAST attack|BEAST]] attack breaks all block ciphers (CBC ciphers) used in SSL 3.0 and TLS 1.0 unless mitigated by the client or the server. See {{section link||Web browsers}}.</ref><ref group="n"name="POODLEciphertable">The [[POODLE]] attack breaks all block ciphers (CBC ciphers) used in SSL 3.0 unless mitigated by the client or the server. See {{section link||Web browsers}}.</ref>
!TLS 1.0<br/><ref group="n"name="rfc5746"/><ref group="n"name="BEAST"/>
!TLS 1.1<br/><ref group="n"name="rfc5746"/>
!TLS 1.2<br/><ref group="n"name="rfc5746"/>
!TLS 1.3
|-
! rowspan="17" {{verth|va=middle|[[Block cipher]] with [[Block cipher mode of operation|mode of operation]]}}
![[Advanced Encryption Standard|AES]] [[Galois/Counter Mode|GCM]]<ref name="aes-gcm">{{IETF RFC|5288|5289}}</ref><ref group="n"name="aead">[[AEAD block cipher modes of operation|AEAD]] ciphers (such as [[Galois/Counter Mode|GCM]] and [[CCM mode|CCM]]) can only be used in TLS 1.2 or later.</ref>
|rowspan=3|256, 128
|{{N/A}}||{{N/A}}||{{N/A}}||{{N/A}}||{{Good|Secure}}||{{Good|Secure}}||rowspan="9"|Defined for TLS 1.2 in RFCs
|-
![[Advanced Encryption Standard|AES]] [[CCM mode|CCM]]<ref name="aes-ccm">{{IETF RFC|6655|7251}}</ref><ref group="n"name="aead"/>
|{{N/A}}||{{N/A}}||{{N/A}}||{{N/A}}||{{Good|Secure}}||{{Good|Secure}}
|-
![[Advanced Encryption Standard|AES]] [[Cipher block chaining|CBC]]<ref group="n"name=Lucky13/>
|{{N/A}}||{{Bad|Insecure}}||{{Depends|Depends on mitigations}}||{{Depends|Depends on mitigations}}||{{Depends|Depends on mitigations}}||{{N/A}}
|-
![[Camellia (cipher)|Camellia]] [[Galois/Counter Mode|GCM]]<ref name="camellia-gcm">{{IETF RFC|6367}}</ref><ref group="n"name="aead"/>
|rowspan=2|256, 128
|{{N/A}}||{{N/A}}||{{N/A}}||{{N/A}}||{{Good|Secure}}||{{N/A}}
|-
![[Camellia (cipher)|Camellia]] [[Cipher block chaining|CBC]]<ref name="camellia-cbc">{{IETF RFC|5932|6367}}</ref><ref group="n"name=Lucky13/>
|{{N/A}}||{{Bad|Insecure}}||{{Depends|Depends on mitigations}}||{{Depends|Depends on mitigations}}||{{Depends|Depends on mitigations}}||{{N/A}}
|-
![[ARIA (cipher)|ARIA]] [[Galois/Counter Mode|GCM]]<ref name=aria/><ref group="n"name="aead"/>
|rowspan=2|256, 128
|{{N/A}}||{{N/A}}||{{N/A}}||{{N/A}}||{{Good|Secure}}||{{N/A}}
|-
![[ARIA (cipher)|ARIA]] [[Cipher block chaining|CBC]]<ref name="aria">{{IETF RFC|6209}}</ref><ref group="n"name=Lucky13/>
|{{N/A}}||{{N/A}}||{{Depends|Depends on mitigations}}||{{Depends|Depends on mitigations}}||{{Depends|Depends on mitigations}}||{{N/A}}
|-
![[SEED (cipher)|SEED]] [[Cipher block chaining|CBC]]<ref name="seed-cbc">{{IETF RFC|4162}}</ref><ref group="n"name=Lucky13/>
|128
|{{N/A}}||{{Bad|Insecure}}||{{Depends|Depends on mitigations}}||{{Depends|Depends on mitigations}}||{{Depends|Depends on mitigations}}||{{N/A}}
|-
![[Triple DES|3DES EDE]] [[Cipher block chaining|CBC]]<ref group="n"name=Lucky13>CBC ciphers can be attacked with the [[Lucky Thirteen attack]] if the library is not written carefully to eliminate timing side channels.</ref>{{refn|group="n"|name=Sweet32|The [[Sweet32]] attack breaks block ciphers with a block size of 64 bits.<ref name=Sweet32>{{cite web|url=https://sweet32.info/SWEET32_CCS16.pdf|title=On the Practical (In-)Security of 64-bit Block Ciphers — Collision Attacks on HTTP over TLS and OpenVPN|date=2016-10-28|access-date=2017-06-08|url-status=live|archive-url=https://web.archive.org/web/20170424021101/https://sweet32.info/SWEET32_CCS16.pdf|archive-date=2017-04-24}}</ref>}}
|112{{refn|group="n"|name="3des"|Although the key length of 3DES is 168 bits, effective security strength of 3DES is only 112 bits,<ref name=NIST_SP_800-57>{{cite web|url=http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf|title=NIST Special Publication 800-57 ''Recommendation for Key Management — Part 1: General (Revised)''|date=2007-03-08|access-date=2014-07-03|url-status=dead|archive-url=https://web.archive.org/web/20140606050814/http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf|archive-date=June 6, 2014}}</ref> which is below the recommended minimum of 128 bits.<ref name="best-practices">{{cite web|url=https://www.ssllabs.com/projects/best-practices/index.html|title=SSL/TLS Deployment Best Practices|author=Qualys SSL Labs|access-date=2 June 2015|url-status=live|archive-url=https://web.archive.org/web/20150704101956/https://www.ssllabs.com/projects/best-practices/index.html|archive-date=4 July 2015}}</ref>}}
|{{Bad|Insecure}}||{{Bad|Insecure}}||{{Bad|Insecure}}||{{Bad|Insecure}}||{{Bad|Insecure}}||{{N/A}}
|-
![[GOST (block cipher)|GOST R 34.12-2015 Magma]] [[Block cipher mode of operation#Counter (CTR)|CTR]]<ref name=gostlink/><ref group="n"name=Sweet32/>
|256
|{{N/A}}||{{N/A}}||{{Bad|Insecure}}||{{Bad|Insecure}}||{{Bad|Insecure}}||{{N/A}}||Defined in {{IETF RFC|4357|9189}}
|-
![[Kuznyechik|GOST R 34.12-2015 Kuznyechik]] [[Block cipher mode of operation#Counter (CTR)|CTR]]<ref name=gostlink/>
|256
|{{N/A}}
|{{N/A}}
|{{N/A}}
|{{N/A}}
|{{Good|Secure}}
|{{N/A}}
|Defined in {{IETF RFC|9189}}
|-
![[GOST (block cipher)|GOST R 34.12-2015 Magma]] [[Authenticated encryption|MGM]]<ref name=gostlink/><ref group="n"name="aead"/><ref group="n"name=Sweet32/>
|256
|{{N/A}}
|{{N/A}}
|{{N/A}}
|{{N/A}}
|{{N/A}}
|{{Bad|Insecure}}
|Defined in {{IETF RFC|9367}}
|-
![[Kuznyechik|GOST R 34.12-2015 Kuznyechik]] [[Authenticated encryption|MGM]]<ref name=gostlink/><ref group="n"name="aead"/>
|256
|{{N/A}}
|{{N/A}}
|{{N/A}}
|{{N/A}}
|{{N/A}}
|{{Good|Secure}}
|Defined in {{IETF RFC|9367}}
|-
![[International Data Encryption Algorithm|IDEA]] [[Cipher block chaining|CBC]]<ref group="n"name=Lucky13/><ref group="n"name=Sweet32/>{{refn|group="n"|name="removal_from_tls1.2"|IDEA and DES have been removed from TLS 1.2.<ref>{{IETF RFC|5469}}</ref>}}
|128
|{{Bad|Insecure}}||{{Bad|Insecure}}||{{Bad|Insecure}}||{{Bad|Insecure}}||{{N/A}}||{{N/A}}||rowspan="2"|Removed from TLS 1.2
|-
!rowspan=2|[[Data Encryption Standard|DES]] [[Cipher block chaining|CBC]]<ref group="n"name=Lucky13/><ref group="n"name=Sweet32/><ref group="n"name="removal_from_tls1.2"/>
|{{0}}56
|{{Bad|Insecure}}||{{Bad|Insecure}}||{{Bad|Insecure}}||{{Bad|Insecure}}||{{N/A}}||{{N/A}}
|-
|{{0}}40<ref group="n"name="EXPORT">40-bit strength cipher suites were intentionally designed with reduced key lengths to comply with since-rescinded US regulations forbidding the export of cryptographic software containing certain strong encryption algorithms (see [[Export of cryptography from the United States]]). These weak suites are forbidden in TLS 1.1 and later.</ref>
|{{Bad|Insecure}}||{{Bad|Insecure}}||{{Bad|Insecure}}||{{N/A}}||{{N/A}}||{{N/A}}||rowspan=2|Forbidden in TLS 1.1 and later
|-
![[RC2]] [[Cipher block chaining|CBC]]<ref group="n"name=Lucky13/><ref group="n"name=Sweet32/>
|{{0}}40<ref group="n"name="EXPORT"/>
|{{Bad|Insecure}}||{{Bad|Insecure}}||{{Bad|Insecure}}||{{N/A}}||{{N/A}}||{{N/A}}
|-
!rowspan=3 {{verth|[[Stream cipher]]}}
![[ChaCha20]]-[[Poly1305]]<ref name="chacha20poly1305">{{IETF RFC|7905}}</ref><ref group="n"name="aead"/>
|256
|{{N/A}}||{{N/A}}||{{N/A}}||{{N/A}}||{{Good|Secure}}||{{Good|Secure}}||Defined for TLS 1.2 in RFCs
|-
!rowspan="2"|[[RC4]]<ref group="n"name="RC4">Use of RC4 in all versions of TLS is prohibited by {{IETF RFC|7465}} (because [[#RC4 attacks|RC4 attacks]] weaken or break RC4 used in SSL/TLS).</ref>
|128
|{{Bad|Insecure}}||{{Bad|Insecure}}||{{Bad|Insecure}}||{{Bad|Insecure}}||{{Bad|Insecure}}||{{N/A}}||rowspan="2"|Prohibited in all versions of TLS by {{IETF RFC|7465}}
|-
|{{0}}40<ref group="n"name="EXPORT"/>
|{{Bad|Insecure}}||{{Bad|Insecure}}||{{Bad|Insecure}}||{{N/A}}||{{N/A}}||{{N/A}}
|-
!{{CNone|None}}
!{{CNone|Null}}<ref group="n">Authentication only, no encryption.</ref>
|–
|{{Bad|Insecure}}||{{Bad|Insecure}}||{{Bad|Insecure}}||{{Bad|Insecure}}||{{Bad|Insecure}}||{{N/A}}||Defined for TLS 1.2 in RFCs
|}
'''Notes'''
{{reflist|group="n"}}

===Data integrity===
A [[message authentication code]] (MAC) is used for data integrity. [[HMAC]] is used for [[cipher block chaining|CBC]] mode of block ciphers. [[Authenticated encryption]] (AEAD) such as [[Galois/Counter Mode|GCM]] and [[CCM mode]] uses AEAD-integrated MAC and does not use [[HMAC]].{{Ref RFC|8446|rsection=8.4}} HMAC-based [[pseudorandom function family|PRF]], or [[HKDF]] is used for TLS handshake.

{{Anchor|integrity-table}}

{|class="wikitable"style=text-align:center
|+Data integrity
!scope=col|Algorithm
!scope=col|SSL 2.0
!scope=col|SSL 3.0
!scope=col|TLS 1.0
!scope=col|TLS 1.1
!scope=col|TLS 1.2
!scope=col|TLS 1.3
!scope=col|Status
|-
!scope=row|[[HMAC]]-[[MD5]]
|{{Yes}}||{{Yes}}||{{Yes}}||{{Yes}}||{{Yes}}||{{No}}||rowspan=4|Defined for TLS 1.2 in RFCs
|-
!scope=row|[[HMAC]]-[[SHA-1|SHA1]]
|{{No}}||{{Yes}}||{{Yes}}||{{Yes}}||{{Yes}}||{{No}}
|-
!scope=row|[[HMAC]]-[[SHA-2|SHA256/384]]
|{{No}}||{{No}}||{{No}}||{{No}}||{{Yes}}||{{No}}
|-
!scope=row|[[AEAD block cipher modes of operation|AEAD]]
|{{No}}||{{No}}||{{No}}||{{No}}||{{Yes}}||{{Yes}}
|-
!scope=row|[[GOST 28147-89|GOST 28147-89 IMIT]]<ref name=gostlink/>
|{{No}}||{{No}}||{{No}}||{{No}}||{{Yes}}||{{No}}||Defined for TLS 1.2 in {{IETF RFC|9189}}.
|-
!scope=row|[[Kuznyechik|GOST R 34.12-2015]] [[AEAD block cipher modes of operation|AEAD]]<ref name=gostlink/>
|{{No}}||{{No}}||{{No}}||{{No}}||{{No}}||{{Yes}}||Defined for TLS 1.3 in {{IETF RFC|9367}}.
|}