Editing Transport Layer Security (section)

==Protocol details==
The TLS protocol exchanges ''records'', which encapsulate the data to be exchanged in a specific format (see below). Each record can be compressed, padded, appended with a [[message authentication code]] (MAC), or encrypted, all depending on the state of the connection. Each record has a ''content type'' field that designates the type of data encapsulated, a length field and a TLS version field. The data encapsulated may be control or procedural messages of the TLS itself, or simply the application data needed to be transferred by TLS. The specifications (cipher suite, keys etc.) required to exchange application data by TLS, are agreed upon in the "TLS handshake" between the client requesting the data and the server responding to requests. The protocol therefore defines both the structure of payloads transferred in TLS and the procedure to establish and monitor the transfer.

===TLS handshake===
[[File:Full TLS 1.2 Handshake.svg|thumb|Simplified illustration of the full TLS 1.2 handshake with timing information]]

When the connection starts, the record encapsulates a "control" protocol – the handshake messaging protocol (''content type'' 22). This protocol is used to exchange all the information required by both sides for the exchange of the actual application data by TLS. It defines the format of messages and the order of their exchange. These may vary according to the demands of the client and server – i.e., there are several possible procedures to set up the connection. This initial exchange results in a successful TLS connection (both parties ready to transfer application data with TLS) or an alert message (as specified below).

====Basic TLS handshake====
A typical connection example follows, illustrating a [[Handshake (computing)|handshake]] where the server (but not the client) is authenticated by its certificate:

#Negotiation phase:
#*A client sends a '''ClientHello''' message specifying the highest TLS protocol version it supports, a random number, a list of suggested [[cipher suite]]s and suggested compression methods. If the client is attempting to perform a resumed handshake, it may send a ''session ID''. If the client can use [[Application-Layer Protocol Negotiation]], it may include a list of supported application [[communications protocol|protocols]], such as [[HTTP/2]].
#*The server responds with a '''ServerHello''' message, containing the chosen protocol version, a random number, cipher suite and compression method from the choices offered by the client. To confirm or allow resumed handshakes the server may send a ''session ID''. The chosen protocol version should be the highest that both the client and server support. For example, if the client supports TLS version 1.1 and the server supports version 1.2, version 1.1 should be selected; version 1.2 should not be selected.
#*The server sends its '''Certificate''' message (depending on the selected cipher suite, this may be omitted by the server).<ref name="openpgp">These certificates are currently [[X.509]], but {{IETF RFC|6091}} also specifies the use of [[OpenPGP]]-based certificates.</ref>
#*The server sends its '''ServerKeyExchange''' message (depending on the selected cipher suite, this may be omitted by the server). This message is sent for all [[Diffie–Hellman key exchange|DHE]], [[ECDHE]] and DH_anon cipher suites.{{ref RFC|5246}}
#*The server sends a '''ServerHelloDone''' message, indicating it is done with handshake negotiation.
#*The client responds with a '''ClientKeyExchange''' message, which may contain a ''PreMasterSecret'', public key, or nothing. (Again, this depends on the selected cipher.) This ''PreMasterSecret'' is encrypted using the public key of the server certificate.
#*The client and server then use the random numbers and ''PreMasterSecret'' to compute a common secret, called the "master secret". All other key data ([[session key]]s such as [[initialization vector|IV]], [[symmetric encryption]] key, [[message authentication code|MAC]] key<ref>{{cite web|title=tls – Differences between the terms "pre-master secret", "master secret", "private key", and "shared secret"?|url=https://crypto.stackexchange.com/questions/27131/differences-between-the-terms-pre-master-secret-master-secret-private-key|access-date=2020-10-01|website=Cryptography Stack Exchange|archive-date=2020-09-22|archive-url=https://web.archive.org/web/20200922021454/https://crypto.stackexchange.com/questions/27131/differences-between-the-terms-pre-master-secret-master-secret-private-key|url-status=live}}</ref>) for this connection is derived from this master secret (and the client- and server-generated random values), which is passed through a carefully designed [[pseudorandomness|pseudorandom]] function.
#The client now sends a '''ChangeCipherSpec''' record, essentially telling the server, "Everything I tell you from now on will be authenticated (and encrypted if encryption parameters were present in the server certificate)." The ChangeCipherSpec is itself a record-level protocol with content type of 20.
#*The client sends an authenticated and encrypted '''Finished''' message, containing a hash and MAC over the previous handshake messages.
#*The server will attempt to decrypt the client's ''Finished'' message and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be terminated.
#Finally, the server sends a '''ChangeCipherSpec''', telling the client, "Everything I tell you from now on will be authenticated (and encrypted, if encryption was negotiated)."
#*The server sends its authenticated and encrypted '''Finished''' message.
#*The client performs the same decryption and verification procedure as the server did in the previous step.
#Application phase: at this point, the "handshake" is complete and the application protocol is enabled, with content type of 23. Application messages exchanged between client and server will also be authenticated and optionally encrypted exactly like in their ''Finished'' message. Otherwise, the content type will return 25 and the client will not authenticate.

====Client-authenticated TLS handshake====
The following ''full'' example shows a client being authenticated (in addition to the server as in the example above; see [[mutual authentication]]) via TLS using certificates exchanged between both peers.

#Negotiation Phase:
#*A client sends a '''ClientHello''' message specifying the highest TLS protocol version it supports, a random number, a list of suggested cipher suites and compression methods.
#*The server responds with a '''ServerHello''' message, containing the chosen protocol version, a random number, cipher suite and compression method from the choices offered by the client. The server may also send a ''session id'' as part of the message to perform a resumed handshake.
#*The server sends its '''Certificate''' message (depending on the selected cipher suite, this may be omitted by the server).<ref name="openpgp"/>
#*The server sends its '''ServerKeyExchange''' message (depending on the selected cipher suite, this may be omitted by the server). This message is sent for all DHE, ECDHE and DH_anon ciphersuites.{{Ref|5246|rsection=7.4.3}}
#*The server sends a '''CertificateRequest''' message, to request a certificate from the client.
#*The server sends a '''ServerHelloDone''' message, indicating it is done with handshake negotiation.
#*The client responds with a '''Certificate''' message, which contains the client's certificate, but not its private key.
#*The client sends a '''ClientKeyExchange''' message, which may contain a ''PreMasterSecret'', public key, or nothing. (Again, this depends on the selected cipher.) This ''PreMasterSecret'' is encrypted using the public key of the server certificate.
#*The client sends a '''CertificateVerify''' message, which is a signature over the previous handshake messages using the client's certificate's private key. This signature can be verified by using the client's certificate's public key. This lets the server know that the client has access to the private key of the certificate and thus owns the certificate.
#*The client and server then use the random numbers and ''PreMasterSecret'' to compute a common secret, called the "master secret". All other key data ("session keys") for this connection is derived from this master secret (and the client- and server-generated random values), which is passed through a carefully designed pseudorandom function.
#The client now sends a '''ChangeCipherSpec''' record, essentially telling the server, "Everything I tell you from now on will be authenticated (and encrypted if encryption was negotiated). "The ChangeCipherSpec is itself a record-level protocol and has type 20 and not 22.
#*Finally, the client sends an encrypted '''Finished''' message, containing a hash and MAC over the previous handshake messages.
#*The server will attempt to decrypt the client's ''Finished'' message and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down.
#Finally, the server sends a '''ChangeCipherSpec''', telling the client, "Everything I tell you from now on will be authenticated (and encrypted if encryption was negotiated)."
#*The server sends its own encrypted '''Finished''' message.
#*The client performs the same decryption and verification procedure as the server did in the previous step.
#Application phase: at this point, the "handshake" is complete and the application protocol is enabled, with content type of 23. Application messages exchanged between client and server will also be encrypted exactly like in their ''Finished'' message.

====Resumed TLS handshake====
Public key operations (e.g., RSA) are relatively expensive in terms of computational power. TLS provides a secure shortcut in the handshake mechanism to avoid these operations: resumed sessions. Resumed sessions are implemented using session IDs or session tickets.

Apart from the performance benefit, resumed sessions can also be used for [[single sign-on]], as it guarantees that both the original session and any resumed session originate from the same client. This is of particular importance for the [[FTPS|FTP over TLS/SSL]] protocol, which would otherwise suffer from a man-in-the-middle attack in which an attacker could intercept the contents of the secondary data connections.<ref>{{cite web|author=Chris|url=http://scarybeastsecurity.blogspot.com/2009/02/vsftpd-210-released.html|title=vsftpd-2.1.0 released – Using TLS session resume for FTPS data connection authentication|publisher=Scarybeastsecurity. blogspot.com|date=2009-02-18|access-date=2012-05-17|url-status=live|archive-url=https://web.archive.org/web/20120707213409/http://scarybeastsecurity.blogspot.com/2009/02/vsftpd-210-released.html|archive-date=2012-07-07}}</ref>

====TLS 1.3 handshake====

The TLS 1.3 handshake was condensed to only one round trip compared to the two round trips required in previous versions of TLS/SSL.

To start the handshake, the client guesses which key exchange algorithm will be selected by the server and sends a '''ClientHello''' message to the server containing a list of supported ciphers (in order of the client's preference) and public keys for some or all of its key exchange guesses. If the client successfully guesses the key exchange algorithm, 1 round trip is eliminated from the handshake. After receiving the '''ClientHello''', the server selects a cipher and sends back a '''ServerHello''' with its own public key, followed by server '''Certificate''' and '''Finished''' messages.<ref>{{cite IETF|title= The Transport Layer Security (TLS) Protocol Version 1.3|rfc=8446|section=4.1.1 |sectionname=Cryptographic Negotiation|publisher=IETF |date=August 2018 |last1=Rescorla |first1=Eric }}</ref>

After the client receives the server's finished message, it now is coordinated with the server on which cipher suite to use.<ref>{{cite web|last=Valsorda|first=Filippo|title=An overview of TLS 1.3 and Q&A|url=https://blog.cloudflare.com/tls-1-3-overview-and-q-and-a|website=The Cloudflare Blog|date=23 September 2016|access-date=3 May 2019|archive-date=3 May 2019|archive-url=https://web.archive.org/web/20190503043936/https://blog.cloudflare.com/tls-1-3-overview-and-q-and-a/|url-status=live}}</ref>

=====Session IDs=====
In an ordinary ''full'' handshake, the server sends a ''session id'' as part of the '''ServerHello''' message. The client associates this ''session id'' with the server's IP address and TCP port, so that when the client connects again to that server, it can use the ''session id'' to shortcut the handshake. In the server, the ''session id'' maps to the cryptographic parameters previously negotiated, specifically the "master secret". Both sides must have the same "master secret" or the resumed handshake will fail (this prevents an eavesdropper from using a ''session id''). The random data in the '''ClientHello''' and '''ServerHello''' messages virtually guarantee that the generated connection keys will be different from in the previous connection. In the RFCs, this type of handshake is called an ''abbreviated'' handshake. It is also described in the literature as a ''restart'' handshake.

#Negotiation phase:
#*A client sends a '''ClientHello''' message specifying the highest TLS protocol version it supports, a random number, a list of suggested cipher suites and compression methods. Included in the message is the ''session id'' from the previous TLS connection.
#*The server responds with a '''ServerHello''' message, containing the chosen protocol version, a random number, cipher suite and compression method from the choices offered by the client. If the server recognizes the ''session id'' sent by the client, it responds with the same ''session id''. The client uses this to recognize that a resumed handshake is being performed. If the server does not recognize the ''session id'' sent by the client, it sends a different value for its ''session id''. This tells the client that a resumed handshake will not be performed. At this point, both the client and server have the "master secret" and random data to generate the key data to be used for this connection.
#The server now sends a '''ChangeCipherSpec''' record, essentially telling the client, "Everything I tell you from now on will be encrypted." The ChangeCipherSpec is itself a record-level protocol and has type 20 and not 22.
#*Finally, the server sends an encrypted '''Finished''' message, containing a hash and MAC over the previous handshake messages.
#*The client will attempt to decrypt the server's ''Finished'' message and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down.
#Finally, the client sends a '''ChangeCipherSpec''', telling the server, "Everything I tell you from now on will be encrypted."
#*The client sends its own encrypted '''Finished''' message.
#*The server performs the same decryption and verification procedure as the client did in the previous step.
#Application phase: at this point, the "handshake" is complete and the application protocol is enabled, with content type of 23. Application messages exchanged between client and server will also be encrypted exactly like in their ''Finished'' message.

=====Session tickets=====
{{IETF RFC|5077}} extends TLS via use of session tickets, instead of session IDs. It defines a way to resume a TLS session without requiring that session-specific state is stored at the TLS server.

When using session tickets, the TLS server stores its session-specific state in a session ticket and sends the session ticket to the TLS client for storing. The client resumes a TLS session by sending the session ticket to the server, and the server resumes the TLS session according to the session-specific state in the ticket. The session ticket is encrypted and authenticated by the server, and the server verifies its validity before using its contents.

One particular weakness of this method with [[OpenSSL]] is that it always limits encryption and authentication security of the transmitted TLS session ticket to <code>AES128-CBC-SHA256</code>, no matter what other TLS parameters were negotiated for the actual TLS session.<ref name="ticketsecwp">{{cite web|title=TLS "Secrets": Whitepaper presenting the security implications of the deployment of session tickets (RFC 5077) as implemented in OpenSSL|first=Florent|last=Daignière|publisher=Matta Consulting Limited|access-date=7 August 2013|url=https://media.blackhat.com/us-13/US-13-Daigniere-TLS-Secrets-WP.pdf|url-status=live|archive-url=https://web.archive.org/web/20130806233112/https://media.blackhat.com/us-13/US-13-Daigniere-TLS-Secrets-WP.pdf|archive-date=6 August 2013}}</ref> This means that the state information (the TLS session ticket) is not as well protected as the TLS session itself. Of particular concern is OpenSSL's storage of the keys in an application-wide context (<code>SSL_CTX</code>), i.e. for the life of the application, and not allowing for re-keying of the <code>AES128-CBC-SHA256</code> TLS session tickets without resetting the application-wide OpenSSL context (which is uncommon, error-prone and often requires manual administrative intervention).<ref name="ticketsecslides">{{cite web|title=TLS "Secrets": What everyone forgot to tell you…|first=Florent|last=Daignière|publisher=Matta Consulting Limited|access-date=7 August 2013|url=https://media.blackhat.com/us-13/US-13-Daigniere-TLS-Secrets-Slides.pdf|url-status=live|archive-url=https://web.archive.org/web/20130805134805/https://media.blackhat.com/us-13/US-13-Daigniere-TLS-Secrets-Slides.pdf|archive-date=5 August 2013}}</ref><ref name="botchingpfs">{{cite web|title=How to botch TLS forward secrecy|first=Adam|last=Langley|website=imperialviolet.org|date=27 June 2013|url=https://www.imperialviolet.org/2013/06/27/botchingpfs.html|url-status=live|archive-url=https://web.archive.org/web/20130808221614/https://www.imperialviolet.org/2013/06/27/botchingpfs.html|archive-date=8 August 2013}}</ref>

===TLS record===
This is the general format of all TLS records.

{|class="wikitable"style=width:95%;text-align:center
|+TLS record format, general
|-
!scope=col|Offset
!scope=col style=width:22%|Byte+0
!scope=col style=width:22%|Byte+1
!scope=col style=width:22%|Byte+2
!scope=col style=width:22%|Byte+3
|-
!scope=row|Byte<br />0
|style=background:#dfd|Content type
|colspan=3{{N/A}}
|-
!scope=row rowspan=2|Bytes<br />1–4
|colspan=2 style=background:#fdd|Legacy version
|colspan=2 style=background:#fdd|Length
|-style=background:#fdd
|''(Major)''
|''(Minor)''
|''(bits 15–8)''
|''(bits 7–0)''
|-
!scope=row|Bytes<br />5–(''m''−1)
|colspan=4|Protocol message(s)
|-
!scope=row|Bytes<br />''m''–(''p''−1)
|colspan=4 style=background:#fbb|[[message authentication code|MAC]] (optional)
|-
!scope=row|Bytes<br />''p''–(''q''−1)
|colspan=4 style=background:#fbb|Padding (block ciphers only)
|}

;Content type
:This field identifies the Record Layer Protocol Type contained in this record.
{|class=wikitable
|+Content types
|-
!scope=col|Hex
!scope=col|Dec
!scope=col|Type
|-
!scope=row|0×14
|20
|ChangeCipherSpec
|-
!scope=row|0×15
|21
|Alert
|-
!scope=row|0×16
|22
|Handshake
|-
!scope=row|0×17
|23
|Application
|-
!scope=row|0×18
|24
|Heartbeat
|}

;Legacy version
:This field identifies the major and minor version of TLS prior to TLS 1.3 for the contained message. For a ClientHello message, this need not be the ''highest'' version supported by the client. For TLS 1.3 and later, this must to be set 0x0303 and application must send supported versions in an extra message extension block.
{|class=wikitable
|+Versions
|-
!scope=col|Major<br />version
!scope=col|Minor<br />version
!scope=col|Version type
|-
!scope=row|3
|0
|SSL 3.0
|-
!scope=row|3
|1
|TLS 1.0
|-
!scope=row|3
|2
|TLS 1.1
|-
!scope=row|3
|3
|TLS 1.2
|-
!scope=row|3
|4
|TLS 1.3
|}

;Length
:The length of "protocol message(s)", "MAC" and "padding" fields combined (i.e. ''q''−5), not to exceed 2<sup>14</sup> bytes (16 KiB).
;Protocol message(s)
:One or more messages identified by the Protocol field. Note that this field may be encrypted depending on the state of the connection.
;MAC and padding
:A [[message authentication code]] computed over the "protocol message(s)" field, with additional key material included. Note that this field may be encrypted, or not included entirely, depending on the state of the connection.
:No "MAC" or "padding" fields can be present at end of TLS records before all cipher algorithms and parameters have been negotiated and handshaked and then confirmed by sending a CipherStateChange record (see below) for signalling that these parameters will take effect in all further records sent by the same peer.

====Handshake protocol====
Most messages exchanged during the setup of the TLS session are based on this record, unless an error or warning occurs and needs to be signaled by an Alert protocol record (see below), or the encryption mode of the session is modified by another record (see ChangeCipherSpec protocol below).

{|class="wikitable"style=width:95%;text-align:center
|+TLS record format for handshake protocol
|-
!scope=col|Offset
!scope=col style=width:22%|Byte+0
!scope=col style=width:22%|Byte+1
!scope=col style=width:22%|Byte+2
!scope=col style=width:22%|Byte+3
|-
!scope=row|Byte<br />0
|style=background:#dfd|22
|colspan=3{{N/A}}
|-
!scope=row rowspan=2|Bytes<br />1–4
|colspan=2 style=background:#fdd|Legacy version
|colspan=2 style=background:#fdd|Length
|-style=background:#fdd
|''(Major)''
|''(Minor)''
|''(bits 15–8)''
|''(bits 7–0)''
|-
!scope=row rowspan=2|Bytes<br />5–8
|rowspan=2|Message type
|colspan=3|Handshake message data length
|-style=font-size:90%;line-height:1.2
|''(bits 23–16)''
|''(bits 15–8)''
|''(bits 7–0)''
|-
!scope=row|Bytes<br />9–(''n''−1)
|colspan=4|Handshake message data
|-
!scope=row rowspan=2|Bytes<br />''n''–(''n''+3)
|rowspan=2 style=background:#fdd|Message type
|colspan=3 style=background:#fdd|Handshake message data length
|-style=background:#fdd
|''(bits 23–16)''
|''(bits 15–8)''
|''(bits 7–0)''
|-
!scope=row|Bytes<br />(''n''+4)–
|colspan=4 style=background:#fdd|Handshake message data
|}

;Message type
:This field identifies the handshake message type.

{|class=wikitable
|+Message types
|-
!scope=col|Code
!scope=col|Description
|-
!scope=row|0
|HelloRequest
|-
!scope=row|1
|ClientHello
|-
!scope=row|2
|ServerHello
|-
!scope=row|4
|NewSessionTicket
|-
!scope=row|8
|EncryptedExtensions (TLS 1.3 only)
|-
!scope=row|11
|Certificate
|-
!scope=row|12
|ServerKeyExchange
|-
!scope=row|13
|CertificateRequest
|-
!scope=row|14
|ServerHelloDone
|-
!scope=row|15
|CertificateVerify
|-
!scope=row|16
|ClientKeyExchange
|-
!scope=row|20
|Finished
|}

;Handshake message data length
:This is a 3-byte field indicating the length of the handshake data, not including the header.

Note that multiple handshake messages may be combined within one record.

====Alert protocol====
This record should normally not be sent during normal handshaking or application exchanges. However, this message can be sent at any time during the handshake and up to the closure of the session. If this is used to signal a fatal error, the session will be closed immediately after sending this record, so this record is used to give a reason for this closure. If the alert level is flagged as a warning, the remote can decide to close the session if it decides that the session is not reliable enough for its needs (before doing so, the remote may also send its own signal).

{|class="wikitable"style=width:95%;text-align:center
|+TLS record format for alert protocol
|-
!scope=col|Offset
!scope=col style=width:22%|Byte+0
!scope=col style=width:22%|Byte+1
!scope=col style=width:22%|Byte+2
!scope=col style=width:22%|Byte+3
|-
!scope=row|Byte<br />0
|style=background:#dfd|21
|colspan=3{{N/A}}
|-
!scope=row rowspan=2|Bytes<br />1–4
|colspan=2 style=background:#fdd|Legacy version
|colspan=2 style=background:#fdd|Length
|-style=background:#fdd
|''(Major)''
|''(Minor)''
|0
|2
|-
!Bytes<br />5–6
|Level
|Description
|colspan=2{{N/A}}
|-
!Bytes<br />''7''–(''p''−1)
|colspan=4 style=background:#fbb|[[message authentication code|MAC]] (optional)
|-
!Bytes<br />''p''–(''q''−1)
|colspan=4 style=background:#fbb|Padding (block ciphers only)
|}

;Level
:This field identifies the level of alert. If the level is fatal, the sender should close the session immediately. Otherwise, the recipient may decide to terminate the session itself, by sending its own fatal alert and closing the session itself immediately after sending it. The use of Alert records is optional, however if it is missing before the session closure, the session may be resumed automatically (with its handshakes).
:Normal closure of a session after termination of the transported application should preferably be alerted with at least the ''Close notify'' Alert type (with a simple warning level) to prevent such automatic resume of a new session. Signalling explicitly the normal closure of a secure session before effectively closing its transport layer is useful to prevent or detect attacks (like attempts to truncate the securely transported data, if it intrinsically does not have a predetermined length or duration that the recipient of the secured data may expect).
{|class="wikitable"style=width:90%
|+Alert level types
|-
!scope=col|Code
!scope=col|Level type
!scope=col|Connection state
|-
!scope=row|1
|style=background:yellow;text-align:center|'''warning'''
|connection or security may be unstable.
|-
!scope=row|2
|style=background:red;text-align:center|'''fatal'''
|connection or security may be compromised, or an unrecoverable error has occurred.
|}

;Description
:This field identifies which type of alert is being sent.
{|class="wikitable"style=width:90%
|+Alert description types
|-
!scope=col|Code
!scope=col|Description
!scope=col|Level types
!scope=col|Note
|-
!scope=row|0
|Close notify
|style=background:orange;text-align:center|'''warning'''/'''fatal'''
|
|-
!scope=row|10
|Unexpected message
|style=background:red;text-align:center|'''fatal'''
|
|-
!scope=row|20
|Bad record MAC
|style=background:red;text-align:center|'''fatal'''
|Possibly a bad SSL implementation, or payload has been tampered with e.g. FTP firewall rule on [[FTPS]] server.
|-
!scope=row|21
|Decryption failed
|style=background:red;text-align:center|'''fatal'''
|TLS only, reserved
|-
!scope=row|22
|Record overflow
|style=background:red;text-align:center|'''fatal'''
|TLS only
|-
!scope=row|30
|Decompression failure
|style=background:red;text-align:center|'''fatal'''
|
|-
!scope=row|40
|Handshake failure
|style=background:red;text-align:center|'''fatal'''
|
|-
!scope=row|41
|No certificate
|style=background:orange;text-align:center|'''warning'''/'''fatal'''
|SSL 3.0 only, reserved
|-
!scope=row|42
|Bad certificate
|style=background:orange;text-align:center|'''warning'''/'''fatal'''
|
|-
!scope=row|43
|Unsupported certificate
|style=background:orange;text-align:center|'''warning'''/'''fatal'''
|e.g. certificate has only server authentication usage enabled and is presented as a client certificate
|-
!scope=row|44
|Certificate revoked
|style=background:orange;text-align:center|'''warning'''/'''fatal'''
|
|-
!scope=row|45
|Certificate expired
|style=background:orange;text-align:center|'''warning'''/'''fatal'''
|Check server certificate expire also check no certificate in the chain presented has expired
|-
!scope=row|46
|Certificate unknown
|style=background:orange;text-align:center|'''warning'''/'''fatal'''
|
|-
!scope=row|47
|Illegal parameter
|style=background:red;text-align:center|'''fatal'''
|
|-
!scope=row|48
|Unknown CA ([[Certificate authority]])
|style=background:red;text-align:center|'''fatal'''
|TLS only
|-
!scope=row|49
|Access denied
|style=background:red;text-align:center|'''fatal'''
|TLS only – e.g. no client certificate has been presented (TLS: Blank certificate message or SSLv3: No Certificate alert), but server is configured to require one.
|-
!scope=row|50
|Decode error
|style=background:red;text-align:center|'''fatal'''
|TLS only
|-
!scope=row|51
|Decrypt error
|style=background:orange;text-align:center|'''warning'''/'''fatal'''
|TLS only
|-
!scope=row|60
|Export restriction
|style=background:red;text-align:center|'''fatal'''
|TLS only, reserved
|-
!scope=row|70
|Protocol version
|style=background:red;text-align:center|'''fatal'''
|TLS only
|-
!scope=row|71
|Insufficient security
|style=background:red;text-align:center|'''fatal'''
|TLS only
|-
!scope=row|80
|Internal error
|style=background:red;text-align:center|'''fatal'''
|TLS only
|-
!scope=row|86
|Inappropriate fallback
|style=background:red;text-align:center|'''fatal'''
|TLS only
|-
!scope=row|90
|User canceled
|style=background:red;text-align:center|'''fatal'''
|TLS only
|-
!scope=row|100
|No renegotiation
|style=background:yellow;text-align:center|'''warning'''
|TLS only
|-
!scope=row|110
|Unsupported extension
|style=background:yellow;text-align:center|'''warning'''
|TLS only
|-
!scope=row|111
|Certificate unobtainable
|style=background:yellow;text-align:center|'''warning'''
|TLS only
|-
!scope=row|112
|Unrecognized name
|style=background:orange;text-align:center|'''warning'''/'''fatal'''
|TLS only; client's [[Server Name Indication|Server Name Indicator]] specified a [[hostname]] not supported by the server
|-
!scope=row|113
|Bad certificate status response
|style=background:red;text-align:center|'''fatal'''
|TLS only
|-
!scope=row|114
|Bad certificate hash value
|style=background:red;text-align:center|'''fatal'''
|TLS only
|-
!scope=row|115
|Unknown [[Pre-shared key|PSK]] identity (used in [[TLS-PSK]] and [[TLS-SRP]])
|style=background:red;text-align:center|'''fatal'''
|TLS only
|-
!scope=row|116
|Certificate required
|style=background:red;text-align:center|'''fatal'''
|TLS version 1.3 only
|-
!scope=row|120 or 255
|No application protocol
|style=background:red;text-align:center|'''fatal'''
|TLS version 1.3 only
|}

====ChangeCipherSpec protocol====
{|class="wikitable"style=width:95%;text-align:center
|+TLS record format for ChangeCipherSpec protocol
|-
!scope=col|Offset
!scope=col style=width:22%|Byte+0
!scope=col style=width:22%|Byte+1
!scope=col style=width:22%|Byte+2
!scope=col style=width:22%|Byte+3
|-
!scope=row|Byte<br />0
|style=background:#dfd|20
|colspan=3{{N/A}}
|-
!scope=row rowspan=2|Bytes<br />1–4
|colspan=2 style=background:#fdd|Legacy version
|colspan=2 style=background:#fdd|Length
|-style=background:#fdd
|''(Major)''
|''(Minor)''
|0
|1
|-
!Byte<br />5
|CCS protocol type
|colspan=3{{N/A}}
|}

;CCS protocol type
:Currently only 1.

====Application protocol====
{|class="wikitable"style=width:95%;text-align:center
|+TLS record format for application protocol
|-
!scope=col|Offset
!scope=col style=width:22%|Byte+0
!scope=col style=width:22%|Byte+1
!scope=col style=width:22%|Byte+2
!scope=col style=width:22%|Byte+3
|-
!scope=row|Byte<br />0
|style=background:#dfd|23
|colspan=3{{N/A}}
|-
!scope=row rowspan=2|Bytes<br />1–4
|colspan=2 style=background:#fdd|Legacy version
|colspan=2 style=background:#fdd|Length
|-style=background:#fdd
|''(Major)''
|''(Minor)''
|''(bits 15–8)''
|''(bits 7–0)''
|-
!Bytes<br />5–(''m''−1)
|colspan=4|Application data
|-
!Bytes<br />''m''–(''p''−1)
|colspan=4 style=background:#fbb|[[message authentication code|MAC]] (optional)
|-
!Bytes<br />''p''–(''q''−1)
|colspan=4 style=background:#fbb|Padding (block ciphers only)
|}

;Length
:Length of application data (excluding the protocol header and including the MAC and padding trailers)
;MAC
:32 bytes for the [[SHA-256]]-based [[HMAC]], 20 bytes for the [[SHA-1]]-based HMAC, 16 bytes for the [[MD5]]-based HMAC.
;Padding
:Variable length; last byte contains the padding length.