As we move the communication and various aspects of life online, ensuring the secure communication through the internet has only grown in importance. It is essential, as for example, that the financial transactions executed on the web and apps are secure and untampered. Security of the networked communication and the Internet in general ensures the confidentiality, integrity, and availability of data.

To achieve such security, security protocols for the Internet have been developed and evolved as internet becomes more pervasive and connects more people, applications, and systems. One of the security protocols is Secure Socket Layer (SSL), which is often used to refer to Transport Layer Security (TLS). The SSL/TLS protocol specifies a set of rules for establishing secure communication between two endpoints, a client and a server, over non secure network.

SSL/TLS Protocol Timeline

SSL is the precursor to TLS, the current protocol used to secure HTTP. SSL was initially developed at Netscape but the specification was later opened to IETF as the relevant Internet standardization body. SSL 2.0 was released in February 1995 and more than a year later, in November 1996, SSL 3.0 was released. The first TLS specification, TLS 1.0, was largely adopted from SSL 3.0 and published by IETF in 1999, the same year with the release of HTTP 1.1 specification. Following the release of TLS 1.0, transition to TLS from SSL gradually occurred. TLS 1.1 was published in 2006. Two years later, in 2008, TLS 1.2 was published. TLS 1.3, which is currently the latest version of TLS, was published in 2018. The picture below visualizes the release timeline for SSL and TLS combined with that of HTTP as the referenced protocol.

Eventhough, TLS was first released in 1999, full adoption of TLS as the protocol for securing HTTP took some good years. SSL 2.0 was deprecated in 2011 via RFC 6176. Meanwhile, SSL 3.0 end of life was marked by the release of RFC 7568 in 2015. It took around 19 years for SSL 3.0 to be around before finally being deprecated. As the ancestor protocol of TLS, it might not be surprising to find HTTPS associated with HTTP with SSL instead of HTTP with TLS. Correspondingly, SSL certificate is also often used when referring to TLS certificate.

TLS is a layered protocol. It consists of two layers: handshake layer and record layer. The handshake layer handles authentication between client and server, client-server negotiation for cryptographic modes and parameters, and establishment of shared keys. The record layer uses the parameters established by the handshake layer to protect the traffic / data communicated between the client and server. Handshake and record layers also exist in SSL. However, details on message handling routines and client-server communication managed by each layer have been changed as the protocol evolved from SSL to TLS and from TLS 1.0 to TLS 1.3.

The evolution of the SSL/TLS protocol mainly follows the theme around achieving better security while maintaining performance. As an example, SSL 3.0 deprecation was influenced by POODLE attack vulnerability, a man-in-the-middle attack that breaks the encryption and recovers the plain text by exploiting non deterministic nature of Cipher Block Chaining (CBC) construction in SSL 3.0. Similarly, TLS 1.0 and TLS 1.1 were deprecated in 2021 due to weak ciphers used for encryption that were included in both specifications.

SSL/TLS Handshake Comparison

Since security parameters are established by the handshake layer, we will review the handshake mechanism for each SSL/TLS version. There are two types of handshake: full handshake and abbreviated handshake. Full handshake is performed in the first communication between client and server. During full handshake, client and server agree on protocol version, choose cryptographic algorithms, optionally authenticate each other, and use public-key encryption techniques to generate shared secrets. Meanwhile, abbreviated handshake is performed when client and server decide to resume a previous communication session or duplicate an existing session instead of negotiating new security parameters.

For SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2, full handshake between client and server follows the same interaction flow as depicted in the following diagrams.

Referring to the diagram, the full handshake steps for SSL 3.0, TLS 1.0, TLS 1.1, and TLS 1.2 can be explained as follows:

1. Client sends ClientHello message to server. The message contains SSL/TLS protocol version, session ID, cipher suite, compression method, and random number.
2. Server sends ServerHello message to client. The message contains SSL/TLS protocol version, session ID, cipher suite, compression method and random number. By exchanging hello message, client and server agree on the TLS protocol version and cipher suites to be used in the handshake.
3. (Optional) Server sends its Certificate to client to be authenticated.
4. (Optional) Server sends ServerKeyExchange message to client. This message contains cryptographic information (key exchange algorithm and parameters) to allow the client to exchange a premaster secret.
5. (Optional) Server sends CertificateRequest message to client to request for client certificate.
6. Server sends ServerHelloDone message to client. Hello-message phase of the handshake is complete.
7. (Optional) Client sends its Certificate to server if previously server has sent CertificateRequest message (Step 5).
8. Client sends ClientKeyExchange message to server. This message conveys the premaster secret, that can be a secret number generated and encrypted by client based on server certificate or client Diffie-Hellman parameters to be used by server to compute the same premaster secret.
9. (Optional) Client sends CertificateVerify if client previously sent a certificate with signing ability.
10. Client sends ChangeCipherSpec message to server and copies pending CipherSpec into its current CipherSpec.
11. Client sends Finished message that can be deconstructed to derive the master secret.
12. Server sends ChangeCipherSpec message to client and transfers pending CipherSpec into its current CipherSpec.
13. Server sends Finished message that is constructed with the new CipherSpec. Handshake is complete and similarly master secret can be derived from the message.
14. Once handshake is finished, client and server begin to exchange application layer data. The data is fragmented, compressed, and encrypted using session keys that are generated from the master secret.

Regardless of same handshake steps for SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2, the details of how each step is executed can be different in each of protocol versions. As an example, SSL 3.0 supports FORTEZZA cipher suite to generate shared keys and secrets during key exchange. TLS 1.0 removes FORTEZZA cipher suite for key exchange and supports only RSA and Diffie-Hellman.

Moving on to TLS 1.3, the full handshake has been significantly modified to ensure better security and improved performance during handshake and subsequent application data transmission. Less secure encryption algorithms (RC4, 3DES, Camellia) and hash algorithms (MD5, SHA-1) are removed from the protocol. A new message type, EncryptedExtensions message, is also introduced to early protect information related with the handshake that if sent unencrypted may help an adversary break the secure communication. In previous TLS versions, messages are encrypted after exchanging ChangeCipherSpec message. In TLS 1.3, however, the messages exchanged after ServerHello message are practically encrypted.

To provide better clarity, the full handshake in TLS 1.3 is depicted in the following diagram.

As can be seen in the diagram, the full handshake in TLS 1.3 is performed as follows.

1. Client sends ClientHello message to server. This message contains cipher suite, client random number, legacy fields for backward compatibility (protocol version, session ID, compression method) and newly introduced variable-length extensions that correspond to extended functionalities from server.
2. (Optional) Client sends several extension requests. First notable extension is key share that is required for (EC)DHE key exchange.
3. (Optional) Client sends signature algorithms extension that is required for certificate authentication.
4. (Optional) Client sends PSK key exchange modes extension that is required for Pre-Shared Key (PSK) key agreement.
5. (Optional) Client sends pre-shared key extension that is required for PSK key agreement.
6. Server sends ServerHello message to client. This message contains cipher suite, server random number, legacy fields (protocol version, session ID, compression method), followed by certain extensions (supported versions, pre-shared key, key share), which are required to establish the cryptographic context.
7. (Optional) Server sends key share extension that informs client whether PSK or (EC)DHE with certificate-based authentication is used.
8. (Optional) Server sends pre-shared key extension indicating the selected key.
9. Server sends EncryptedExtensions message.The message contains extensions (additional data such as server name, max fragment length, certificate type, etc) that are not needed to establish cryptographic context but help extend the functionality provided by corresponding TLS protocol messages.
10. (Optional) Server sends CertificateRequest to client to request for client certificate.
11. (Optional) Server sends its Certificate to client to be authenticated.
12. (Optional) Server sends CertificateVerify message that contains server signature over the handshake generated using its private key.
13. Server sends Finished message that authenticates the handshake and contains the computed key.
14. (Optional) Client and server may send other messages that are encrypted under the appropriate application traffic key while waiting for client to finish the handshake.
15. (Optional) Client sends its certificate to server to be authenticated.
16. (Optional) Client sends CertificateVerify message that contains the client signature.
17. Client sends Finished message to authenticate the handshake.

TLS 1.3 also introduces 0-RTT handshake that allows clients to send data on the first flight without waiting for completing cryptographic negotiation with server. The 0-RTT handshake is applicable when clients and servers share a PSK that was obtained externally or via previous handshake. The client uses the PSK to authenticate the server and to encrypt the early data.

Reflecting to the TLS handshake and subsequent application data transmission, there are at least three aspects addressed to ensure secure communication between client and server:

• Privacy: conversation must only be understood by / transparent to client and server, and not other party. This necessitates encryption of messages. TLS addresses this aspect through symmetric key encryption for application data.
• Integrity: client and server must be able to detect message tampering. TLS addresses this aspect through authenticated encryption with additional data (AEAD)
• Authentication: each party needs to trust that they are communicating to the intended counterpart. TLS addresses this through server and client certificate.

As can be seen on the handshake diagram, client and/or server authentication occurs during the handshake. To authenticate to the other party, client or server shall present its certificate. By providing the certificate to the other party, client or server seeks to prove that its identity is the same as it claims. Note that certificate requests from client to server and from server to client are optional. However, for the case where a user accesses a website through a browser, the common practice is that the client (browser) will request for server (website) certificate while server does not request for client certificate.

SSL/TLS Cipher Suite Comparison

A cipher is an algorithm, a set of steps or routines that are used to perform a specific mathematical function for the purpose of generating encryption, hashing, or digital signature. A cipher suite is a set of algorithms used to negotiate security settings especially during SSL/TLS handshake. A cipher suite includes algorithms for key exchange, authentication/digital signature, bulk encryption, and message authentication code (MAC).

SSL 3.0 specifies the following cipher suites:

No	Cipher Suite Name
1	SSL_NULL_WITH_NULL_NULL
2	SSL_RSA_WITH_NULL_MD5
3	SSL_RSA_WITH_NULL_SHA
4	SSL_RSA_EXPORT_WITH_RC4_40_MD5
5	SSL_RSA_WITH_RC4_128_MD5
6	SSL_RSA_WITH_RC4_128_SHA
7	SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
8	SSL_RSA_WITH_IDEA_CBC_SHA
9	SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
10	SSL_RSA_WITH_DES_CBC_SHA
11	SSL_RSA_WITH_3DES_EDE_CBC_SHA
12	SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
13	SSL_DH_DSS_WITH_DES_CBC_SHA
14	SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA
15	SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
16	SSL_DH_RSA_WITH_DES_CBC_SHA
17	SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA
18	SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
19	SSL_DHE_DSS_WITH_DES_CBC_SHA
20	SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
21	SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
22	SSL_DHE_RSA_WITH_DES_CBC_SHA
23	SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
24	SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
25	SSL_DH_anon_WITH_RC4_128_MD5
26	SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
27	SSL_DH_anon_WITH_DES_CBC_SHA
28	SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
29	SSL_FORTEZZA_KEA_WITH_NULL_SHA
30	SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA
31	SSL_FORTEZZA_KEA_WITH_RC4_128_SHA

For TLS 1.0, the following cipher suites are defined in the RFC:

No	Cipher Suite Name
1	TLS_NULL_WITH_NULL_NULL
2	TLS_RSA_WITH_NULL_MD5
3	TLS_RSA_WITH_NULL_SHA
4	TLS_RSA_EXPORT_WITH_RC4_40_MD5
5	TLS_RSA_WITH_RC4_128_MD5
6	TLS_RSA_WITH_RC4_128_SHA
7	TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
8	TLS_RSA_WITH_IDEA_CBC_SHA
9	TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
10	TLS_RSA_WITH_DES_CBC_SHA
11	TLS_RSA_WITH_3DES_EDE_CBC_SHA
12	TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
13	TLS_DH_DSS_WITH_DES_CBC_SHA
14	TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
15	TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
16	TLS_DH_RSA_WITH_DES_CBC_SHA
17	TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
18	TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
19	TLS_DHE_DSS_WITH_DES_CBC_SHA
20	TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
21	TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
22	TLS_DHE_RSA_WITH_DES_CBC_SHA
23	TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
24	TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
25	TLS_DH_anon_WITH_RC4_128_MD5
26	TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
27	TLS_DH_anon_WITH_DES_CBC_SHA
28	TLS_DH_anon_WITH_3DES_EDE_CBC_SHA

TLS 1.1 specifies the 19 cipher suites as follows:

No	Cipher Suite Name
1	TLS_NULL_WITH_NULL_NULL
2	TLS_RSA_WITH_NULL_MD5
3	TLS_RSA_WITH_NULL_SHA
4	TLS_RSA_WITH_RC4_128_MD5
5	TLS_RSA_WITH_RC4_128_SHA
6	TLS_RSA_WITH_IDEA_CBC_SHA
7	TLS_RSA_WITH_DES_CBC_SHA
8	TLS_RSA_WITH_3DES_EDE_CBC_SHA
9	TLS_DH_DSS_WITH_DES_CBC_SHA
10	TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
11	TLS_DH_RSA_WITH_DES_CBC_SHA
12	TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
13	TLS_DHE_DSS_WITH_DES_CBC_SHA
14	TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
15	TLS_DHE_RSA_WITH_DES_CBC_SHA
16	TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
17	TLS_DH_anon_WITH_RC4_128_MD5
18	TLS_DH_anon_WITH_DES_CBC_SHA
19	TLS_DH_anon_WITH_3DES_EDE_CBC_SHA

TLS 1.2 specifies the most cipher suites at 37. The list of cipher suites defined in TLS 1.2 is as follows.

No	Cipher Suite Name
1	TLS_NULL_WITH_NULL_NULL
2	TLS_RSA_WITH_NULL_MD5
3	TLS_RSA_WITH_NULL_SHA
4	TLS_RSA_WITH_NULL_SHA256
5	TLS_RSA_WITH_RC4_128_MD5
6	TLS_RSA_WITH_RC4_128_SHA
7	TLS_RSA_WITH_3DES_EDE_CBC_SHA
8	TLS_RSA_WITH_AES_128_CBC_SHA
9	TLS_RSA_WITH_AES_256_CBC_SHA
10	TLS_RSA_WITH_AES_128_CBC_SHA256
11	TLS_RSA_WITH_AES_256_CBC_SHA256
12	TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
13	TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
14	TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
15	TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
16	TLS_DH_DSS_WITH_AES_128_CBC_SHA
17	TLS_DH_RSA_WITH_AES_128_CBC_SHA
18	TLS_DHE_DSS_WITH_AES_128_CBC_SHA
19	TLS_DHE_RSA_WITH_AES_128_CBC_SHA
20	TLS_DH_DSS_WITH_AES_256_CBC_SHA
21	TLS_DH_RSA_WITH_AES_256_CBC_SHA
22	TLS_DHE_DSS_WITH_AES_256_CBC_SHA
23	TLS_DHE_RSA_WITH_AES_256_CBC_SHA
24	TLS_DH_DSS_WITH_AES_128_CBC_SHA256
25	TLS_DH_RSA_WITH_AES_128_CBC_SHA256
26	TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
27	TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
28	TLS_DH_DSS_WITH_AES_256_CBC_SHA256
29	TLS_DH_RSA_WITH_AES_256_CBC_SHA256
30	TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
31	TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
32	TLS_DH_anon_WITH_RC4_128_MD5
33	TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
34	TLS_DH_anon_WITH_AES_128_CBC_SHA
35	TLS_DH_anon_WITH_AES_256_CBC_SHA
36	TLS_DH_anon_WITH_AES_128_CBC_SHA256
37	TLS_DH_anon_WITH_AES_256_CBC_SHA256

In TLS 1.3, cipher suite selection has been narrowed down. There are only 5 cipher suites specified for TLS 1.3 as follows.

No	Cipher Suite Name
1	TLS_AES_128_GCM_SHA256
2	TLS_AES_256_GCM_SHA384
3	TLS_CHACHA20_POLY1305_SHA256
4	TLS_AES_128_CCM_SHA256
5	TLS_AES_128_CCM_8_SHA256

SSL/TLS Alert Message Comparison

Messages sent in the record layer may contain alert content. An alert message is sent by the detecting party to the other party. All SSL/TLS specifications define two types of alerts: closure alerts and error alerts. A closure alert indicates closure of information or ending of current connection while an error alert indicate a certain error has occurred. Alert message is encrypted and compressed as specified in the current connection state.

SSL 3.0 specifies alert messages as follows.

No	Alert Type	Alert Code	Alert Number	Description
1	Closure Alert	close_notify	0	Notifies recipient that sender will not send any more messages on the current connection
2	Error Alert	unexpected_message	10	Notifies the other party that an inappropriate message was received
3	Error Alert	bad_record_mac	20	Notifies the other party that a record was received with an incorrect MAC
4	Error Alert	decompression_failure	30	Notifies the other party that decompression function received improper input
5	Error Alert	handshake_failure	40	Notifies recipient that sender was unable to negotiate an acceptable set of security parameters given the options available
6	Error Alert	no_certificate	41	Upon certificate request, notifies the other party that no certificate is available
7	Error Alert	bad_certificate	42	Notifies the other party that a certificate was corrupt, signature could not be verified, etc
8	Error Alert	unsupported_certificate	43	Notifies the other party that the type of certificate provided was not supported
9	Error Alert	certificate_revoked	44	Notifies the other party that a certificate was revoked by its signer
10	Error Alert	certificate_expired	45	Notifies the other party that a certificate has expired or is not currently valid
11	Error Alert	certificate_unknown	46	Notifies the other party that some other issue occurred when processing the certificate provided
12	Error Alert	illegal_parameter	47	Notifies the other party that a field in the handshake was out of range or inconsistent with other fields

TLS 1.0 specifies 1 closure alert and 22 error alerts as follows.

No	Alert Type	Alert Code	Alert Number	Description
1	Closure Alert	close_notify	0	Notifies recipient that sender will not send any more messages on the current connection
2	Error Alert	unexpected_message	10	Notifies the other party that an inappropriate message was received
3	Error Alert	bad_record_mac	20	Notifies the other party that a record was received with an incorrect MAC
4	Error Alert	decryption_failed	21	Notifies the other party that TLS cipher text could not be decrypted due to invalid block length or padding values
5	Error Alert	record_overflow	22	Notifies the other party that TLS cipher text record received exceeded the max length allowed
6	Error Alert	decompression_failure	30	Notifies the other party that decompression function received improper input
7	Error Alert	handshake_failure	40	Notifies recipient that sender was unable to negotiate an acceptable set of security parameters given the options available
8	Error Alert	bad_certificate	42	Notifies the other party that a certificate was corrupt, signature could not be verified, etc
9	Error Alert	unsupported_certificate	43	Notifies the other party that the type of certificate provided was not supported
10	Error Alert	certificate_revoked	44	Notifies the other party that a certificate was revoked by its signer
11	Error Alert	certificate_expired	45	Notifies the other party that a certificate has expired or is not currently valid
12	Error Alert	certificate_unknown	46	Notifies the other party that some other issue occurred when processing the certificate provided
13	Error Alert	illegal_parameter	47	Notifies the other party that a field in the handshake was out of range or inconsistent with other fields
14	Error Alert	unknown_ca	48	Notifies the other party that the provided certificate could not be located or matched with a known or trusted CA
15	Error Alert	access_denied	49	Notifies the recipient that a valid certificate was received but sender decided not to proceed with negotiation
16	Error Alert	decode_error	50	Notifies the other party that a message could not be decoded because some field was out of range or message length was incorrect
17	Error Alert	decrypt_error	51	Notifies the other party that a handshake operation has failed due to failure in verifying signature, decrypting a key exchange, or validating a finished message
18	Error Alert	export_restriction	60	Notifies the other party that a negotiation was not in compliance with export restriction
19	Error Alert	protocol_version	70	Notifies the client that the protocol version negotiated was recognized but not supported
20	Error Alert	insufficient_security	71	Notifies the client that server requires ciphers more secure than those supported by the client
21	Error Alert	internal_error	80	Notifies the other party that an internal error occurred on the sender side
22	Error Alert	user_canceled	90	Notifies the other party that handshake was canceled due to other reason unrelated to protocol failure
23	Error Alert	no_renegotiation	100	Notifies the other party that renegotiation during the handshake is not appropriate

TLS 1.1 defines 1 closure alert and 23 error alerts as follows.

No	Alert Type	Alert Code	Alert Number	Description
1	Closure Alert	close_notify	0	Notifies recipient that sender will not send any more messages on the current connection
2	Error Alert	unexpected_message	10	Notifies the other party that an inappropriate message was received
3	Error Alert	bad_record_mac	20	Notifies the other party that a record was received with an incorrect MAC
4	Error Alert	decryption_failed	21	Notifies the other party that TLS cipher text could not be decrypted due to invalid block length or padding values
5	Error Alert	record_overflow	22	Notifies the other party that TLS cipher text record received exceeded the max length allowed
6	Error Alert	decompression_failure	30	Notifies the other party that decompression function received improper input
7	Error Alert	handshake_failure	40	Notifies recipient that sender was unable to negotiate an acceptable set of security parameters given the options available
8	Error Alert	no_certificate_RESERVED	41	A reserved alert that was used in SSLv3 but not in TLS
9	Error Alert	bad_certificate	42	Notifies the other party that a certificate was corrupt, signature could not be verified, etc
10	Error Alert	unsupported_certificate	43	Notifies the other party that the type of certificate provided was not supported
11	Error Alert	certificate_revoked	44	Notifies the other party that a certificate was revoked by its signer
12	Error Alert	certificate_expired	45	Notifies the other party that a certificate has expired or is not currently valid
13	Error Alert	certificate_unknown	46	Notifies the other party that some other issue occurred when processing the certificate provided
14	Error Alert	illegal_parameter	47	Notifies the other party that a field in the handshake was out of range or inconsistent with other fields
15	Error Alert	unknown_ca	48	Notifies the other party that the provided certificate could not be located or matched with a known or trusted CA
16	Error Alert	access_denied	49	Notifies the recipient that a valid certificate was received but sender decided not to proceed with negotiation
17	Error Alert	decode_error	50	Notifies the other party that a message could not be decoded because some field was out of range or message length was incorrect
18	Error Alert	decrypt_error	51	Notifies the other party that a handshake operation has failed due to failure in verifying signature, decrypting a key exchange, or validating a finished message
19	Error Alert	export_restriction_RESERVED	60	A reserved alert that was used in TLS 1.0 but not in TLS 1.1
20	Error Alert	protocol_version	70	Notifies the client that the protocol version negotiated was recognized but not supported
21	Error Alert	insufficient_security	71	Notifies the client that server requires ciphers more secure than those supported by the client
22	Error Alert	internal_error	80	Notifies the other party that an internal error occurred on the sender side
23	Error Alert	user_canceled	90	Notifies the other party that handshake was canceled due to other reason unrelated to protocol failure
24	Error Alert	no_renegotiation	100	Notifies the other party that renegotiation during the handshake is not appropriate

As can be seen in the table above, alert messages in TLS 1.0 vs TLS 1.1 are only different in two reserved alerts that are defined in TLS 1.1.

For TLS 1.2, there are 1 closure alert and 24 error alerts defined as follows.

No	Alert Type	Alert Code	Alert Number	Description
1	Closure Alert	close_notify	0	Notifies recipient that sender will not send any more messages on the current connection
2	Error Alert	unexpected_message	10	Notifies the other party that an inappropriate message was received
3	Error Alert	bad_record_mac	20	Notifies the other party that a record was received with an incorrect MAC
4	Error Alert	decryption_failed_RESERVED	21	A reserved alert that was used in previous TLS versions (TLS 1.0 and TLS 1.1)
5	Error Alert	record_overflow	22	Notifies the other party that TLS cipher text record received exceeded the max length allowed
6	Error Alert	decompression_failure	30	Notifies the other party that decompression function received improper input
7	Error Alert	handshake_failure	40	Notifies recipient that sender was unable to negotiate an acceptable set of security parameters given the options available
8	Error Alert	no_certificate_RESERVED	41	A reserved alert that was used in SSLv3 but not in TLS
9	Error Alert	bad_certificate	42	Notifies the other party that a certificate was corrupt, signature could not be verified, etc
10	Error Alert	unsupported_certificate	43	Notifies the other party that the type of certificate provided was not supported
11	Error Alert	certificate_revoked	44	Notifies the other party that a certificate was revoked by its signer
12	Error Alert	certificate_expired	45	Notifies the other party that a certificate has expired or is not currently valid
13	Error Alert	certificate_unknown	46	Notifies the other party that some other issue occurred when processing the certificate provided
14	Error Alert	illegal_parameter	47	Notifies the other party that a field in the handshake was out of range or inconsistent with other fields
15	Error Alert	unknown_ca	48	Notifies the other party that the provided certificate could not be located or matched with a known or trusted CA
16	Error Alert	access_denied	49	Notifies the recipient that a valid certificate was received but sender decided not to proceed with negotiation
17	Error Alert	decode_error	50	Notifies the other party that a message could not be decoded because some field was out of range or message length was incorrect
18	Error Alert	decrypt_error	51	Notifies the other party that a handshake operation has failed due to failure in verifying signature, decrypting a key exchange, or validating a finished message
19	Error Alert	export_restriction_RESERVED	60	A reserved alert that was used in TLS 1.0 but not in TLS 1.1
20	Error Alert	protocol_version	70	Notifies the client that the protocol version negotiated was recognized but not supported
21	Error Alert	insufficient_security	71	Notifies the client that server requires ciphers more secure than those supported by the client
22	Error Alert	internal_error	80	Notifies the other party that an internal error occurred on the sender side
23	Error Alert	user_canceled	90	Notifies the other party that handshake was canceled due to other reason unrelated to protocol failure
24	Error Alert	no_renegotiation	100	Notifies the other party that renegotiation during the handshake is not appropriate
25	Error Alert	unsupported_extension	110	Sent by client to notify server that an extended server hello received contains extension that was not put in the corresponding client hello

Compared to TLS 1.1, TLS 1.2 introduces new error for unsupported extension. Additionally, TLS 1.2 obsoletes and reserves decryption failure error since handshake mechanism in TLS 1.2 has been modified to prevent Cipher Block Chaining (CBC) attack.

TLS 1.3 contains further modification to alert messages. TLS 1.3 specifies 2 closure alerts and 25 error alerts as can be seen in the table below.

No	Alert Type	Alert Code	Alert Number	Description
1	Closure Alert	close_notify	0	Notifies recipient that sender will not send any more messages on the current connection
2	Closure Alert	user_canceled	90	Notifies the other party that handshake was canceled due to other reason unrelated to protocol failure
3	Error Alert	unexpected_message	10	Notifies the other party that an inappropriate message was received
4	Error Alert	bad_record_mac	20	Notifies the other party that a record was received with an incorrect MAC
5	Error Alert	record_overflow	22	Notifies the other party that TLS cipher text record received exceeded the max length allowed
6	Error Alert	handshake_failure	40	Notifies recipient that sender was unable to negotiate an acceptable set of security parameters given the options available
7	Error Alert	bad_certificate	42	Notifies the other party that a certificate was corrupt, signature could not be verified, etc
8	Error Alert	unsupported_certificate	43	Notifies the other party that the type of certificate provided was not supported
9	Error Alert	certificate_revoked	44	Notifies the other party that a certificate was revoked by its signer
10	Error Alert	certificate_expired	45	Notifies the other party that a certificate has expired or is not currently valid
11	Error Alert	certificate_unknown	46	Notifies the other party that some other issue occurred when processing the certificate provided
12	Error Alert	illegal_parameter	47	Notifies the other party that a field in the handshake was out of range or inconsistent with other fields
13	Error Alert	unknown_ca	48	Notifies the other party that the provided certificate could not be located or matched with a known or trusted CA
14	Error Alert	access_denied	49	Notifies the recipient that a valid certificate was received but sender decided not to proceed with negotiation
15	Error Alert	decode_error	50	Notifies the other party that a message could not be decoded because some field was out of range or message length was incorrect
16	Error Alert	decrypt_error	51	Notifies the other party that a handshake operation has failed due to failure in verifying signature, decrypting a key exchange, or validating a finished message
17	Error Alert	protocol_version	70	Notifies the client that the protocol version negotiated was recognized but not supported
18	Error Alert	insufficient_security	71	Notifies the client that server requires ciphers more secure than those supported by the client
19	Error Alert	internal_error	80	Notifies the other party that an internal error occurred on the sender side
20	Error Alert	inappropriate_fallback	86	Sent by server to notify client on an invalid connection retry attempt
21	Error Alert	missing_extension	109	Notifies the other party that a handshake message received did not contain an extension that is mandatory to send for the TLS version or other required parameters based on negotiation
22	Error Alert	unsupported_extension	110	Notifies the other party that a handshake message contains an extension disallowed to be included in the handshake message
23	Error Alert	unrecognized_name	112	Sent by server when a server identified by the name provided by client in “server_name” extension does not exist
24	Error Alert	bad_certificate_status_response	113	Sent by client when an invalid or unacceptable Online Certificate Status Protocol (OCSP) response is provided by the server via “status_request" extension
25	Error Alert	unknown_psk_identity	115	Sent by server when pre-shared key (PSK) key establishment is desired but no acceptable PSK identity is provided by the client
26	Error Alert	certificate_required	116	Sent by server when a client certificate is desired but none was provided by the client
27	Error Alert	no_application_protocol	120	Sent by server when a client “application_layer_protocol_negotiation” extension advertises only protocols that the server does not support

As can be inferred from the table above, TLS 1.3 reclassifies “user_canceled” alert into closure alert type, removes reserved alerts, and add new alerts related to the new handshake mechanism in the protocol.

SSL/TLS Certificate Support Comparison

The certificate presented by the server to the client or the client to the server during the TLS handshake is referred to as TLS certificate. It is also common for the certificate to be called SSL certificate, similar with how SSL is often used to refer to TLS. The TLS certificate is a type of X.509 certificate, a specification from IETF for digital certificate based on public key infrastructure.

As previously stated, even though the specification governs that TLS certificate be presented by both client and server, in the case of accessing a website on a browser, the common practice is to authenticate the server (website) only. Client certificate authentication may take place in different type of interaction where server concerns about client identity, for example, cross-domain server-to-server API access.

A TLS certificate carries some information that helps certify the identity of the certificate holder as follows:

• X.509 certificate version (v1, v2, or v3).
• Certificate issuer, which is often referred to as Certification Authority (CA), and the CA info (country, organization, representative).
• Serial number, a unique number assigned by the CA that issued the certificate.
• Signature algorithm, the cryptographic algorithm used by the certificate issuer / CA to sign the certificate.
• Signature of the certificate generated by the certificate issuer.
• Certificate validity period (issue date and expiration date).
• Entity / domain name associated with the certificate, hence the certificate holder / public key owner.
• Organization, location, representative, and contact number associated with the certificate holder.
• Public key of the entity / domain name and the algorithm to be used with the public key (RSA, DSA, Diffie-Hellman). The private key is kept secret by the entity.
• Optional additional attributes such as key usage, certificate policies, entity alternative name (email, DNS name, IP address, URI), and certificate constraints.

There are two classes of X.509 certificate that characterize how each class of certificate is used:

• CA certificate: A certificate whereas the holder is authorized to issue certificates
• End entity certificate: A certificate whereas the holder is not authorized to issue certificates

A CA certificate is further categorized into three distinct types:

• Cross-certificate: A certificate where the issuer and the holder are different entities
• Self-issued certificate: A certificate where the issuer and the holder are the same entity.
• Self-signed certificate: A self-issued certificate where the digital signature can be verified by the public key carried in the certificate.

SSL 3.0 supports X.509 v3 certificate or modified X.509 certificate when using FORTEZZA cipher suite. TLS 1.0, TLS 1.1, TLS 1.2 support X.509 v3 certificate only. TLS 1.3 supports X.509 v3 certificate, OpenPGP certificate and raw public keys.

Summary of SSL/TLS Comparisons

Based on the extensive comparisons above, we will summarize the differences between various SSL/TLS versions. The summary is presented as a comparison table as follows.

Item	SSL 3.0	TLS 1.0	TLS 1.1	TLS 1.2	TLS 1.3
Publication date	November 1996	January 1999	April 2006	August 2008	August 2018
Publication RFC	RFC 6101	RFC 2246	RFC 4346	RFC 5246	RFC 8446
Deprecation date	June 2015	March 2021	March 2021	-	-
Deprecation RFC	RFC 7568	RFC 8996	RFC 8996	-	-
Active status	Deprecated	Deprecated	Deprecated	Actively used	Actively used
Security goal	To provide privacy and reliability between two communicating applications	To provide privacy and data integrity between two communicating applications	To provide privacy and data integrity between two communicating applications	To provide privacy and data integrity between two communicating applications	To provide a secure channel that ensures authentication, confidentiality, and integrity between two communicating peers
Handshake	Supports RSA, Diffie-Hellman and Fortezza key exchange algorithms	Removes Fortezza and adds export-controlled key exchange algorithms, uses implicit Initialization Vector (IV)	Supports RSA and Diffie-Hellman key exchange algorithms, uses explicit Initialization Vector (IV), removes export-controlled key exchange algorithms	Supports RSA and Diffie-Hellman key exchange algorithms, removes MD5/SHA-1 in pseudorandom function (PRF), introduces extension in hello messages	Supports (Elliptic Curve) Diffie-Hellman and pre-shared key (PSK) for key exchange algorithms, extensions are encrypted, uses session tickets, introduces 0-RTT handshake
Message encryption	Supports stream and CBC block ciphers (RC2, RC4, IDEA, DES, 3DES, FORTEZZA)	Supports stream and CBC block ciphers (RC2, RC4, IDEA, DES, 3DES)	Supports stream and CBC block ciphers (RC4, IDEA, DES, 3DES)	Supports stream, CBC block ciphers (RC4, 3DES, AES128, AES256), and AEAD ciphers (CCM, GCM)	Supports Authenticated Encryption with Associated Data (AEAD) ciphers (CCM, GCM, POLY1305)
Cipher suites	31 cipher suites	28 cipher suites	19 cipher suites	37 cipher suites	5 cipher suites
Message authentication / hashing	SHA/MD5 to compute MAC baed on master secret, uses MAC-then-encrypt	HMAC with MD5 / SHA-1, uses MAC-then-encrypt	HMAC with MD5 / SHA-1, uses MAC-then-encrypt	HMAC with MD5 / SHA-1 / SHA-256, supports encrypt-then-MAC	HMAC with SHA256 / SHA384, uses encrypt-then-MAC by default
Alert message	1 closure alert, 11 error alerts	1 closure alert, 22 error alerts	1 closure alert, 23 error alerts	1 closure alert, 24 error alerts	2 closure alerts, 25 error alerts
Peer certificate	X.509 v3, modified X.509 v3	X.509 v3	X.509 v3	X.509 v3	X.509 v3, OpenPGP certificate, raw public keys
Vulnerability	POODLE attack (plain text recovery)	CBC attack	CBC attack	Exploitable weak cipher selection (RC4, 3DES)

Which SSL/TLS Version Should Be Used?

SSL/TLS has evolved to better secure communication through the network. SSL/TLS adds encryption on top of unsecured communication channel. By incorporating SSL/TLS into a communication protocol, various aspects of security goals, namely privacy, integrity, and authentication can be achieved.

When implementing or incorporating SSL/TLS to your networked system or application, it is recommended to use TLS 1.3 or TLS 1.2 with proper configuration (strong cipher and key exchange algorithm). This is since the previous versions of SSL/TLS have been found to be vulnerable to plain text recovery or downgraded security attack.