Understanding TLS Protocol

This article will help you in understanding TLS Protocol and difference between it’s various versions.

What is TLS?

Transport Layer Security abbreviated as TLS is a cryptographic protocol designed to provide secure communication between web browsers and servers.TLS is a succesor of Secure Socket Layer (SSL) protocol. Sometimes, TLS is also referred as SSL.

The goals of TLS Protocol, in order of their priority, are:

  • Cryptographic security: TLS should be used to establish a secure connection between two parties.
  • Interoperability: Independent programmers should be able to develop applications utilizing TLS that will then be able to successfully exchange cryptographic parameters without knowledge of one another’s code.
  • Relative efficiency: Cryptographic operations tend to be highly CPU intensive, particularly public key operations. For this reason, the TLS protocol has incorporated an optional session caching scheme to reduce the number of connections that need to be established from scratch. Additionally, care has been taken to reduce network activity.
  • Extensibility: TLS seeks to provide a framework into which new public key and bulk encryption methods can be incorporated as necessary. This will also accomplish two sub-goals: to prevent the need to create a new protocol (and risking the introduction of possible new weaknesses) and to avoid the need to implement an entire new security library.

Versions of TLS protocol

The versions of TLS available to use are TLS 1.0, TLS 1.1, TLS 1.2 and TLS 1.3. Nowadays, It is recommended to use TLS 1.3 protocol as it is considered to be more secure than previous versions.

Although TLSv1.3 is more secure and faster than it’s predecessors, It is not yet as widely used as TLSv1.2. However, It is seeing a trend in it’s adoption rate.

Understanding TLS Protocol : TLS version trends as seen by Cloudflare from May 2018 to May 2019.
TLS version trends as seen by Cloudflare from May 2018 to May 2019.

Main reason TLSv1.3 is faster than TLSv1.2 is how the SSL handshake occurs. The TLS 1.3 handshake process involves only one round-trip as opposed to three in TLS 1.2. This results in reduced latency.

Differences between various TLS versions

TLS 1.0 vs TLS 1.1
– The implicit Initialization Vector (IV) is replaced with an explicit IV to protect against CBC attacks [CBCATT].
– Handling of padding errors is changed to use the bad_record_mac alert rather than the decryption_failed alert to protect against CBC attacks.
– IANA registries are defined for protocol parameters.
– Premature closes no longer cause a session to be nonresumable.
– Additional informational notes were added for various new attacks on TLS.
– In addition, a number of minor clarifications and editorial improvements were made.

TLS 1.1 vs TLS 1.2
– The MD5/SHA-1 combination in the pseudorandom function (PRF) has been replaced with cipher-suite-specified PRFs. All cipher suites in this document use P_SHA256.
– The MD5/SHA-1 combination in the digitally-signed element has been replaced with a single hash. Signed elements now include a field that explicitly specifies the hash algorithm used.
– Substantial cleanup to the client’s and server’s ability to specify which hash and signature algorithms they will accept. Note that this also relaxes some of the constraints on signature and hash algorithms from previous versions of TLS.
– Addition of support for authenticated encryption with additional data modes.
– TLS Extensions definition and AES Cipher Suites were merged in from external [TLSEXT] and [TLSAES].
– Tighter checking of EncryptedPreMasterSecret version numbers.
– Tightened up a number of requirements.
– Verify_data length now depends on the cipher suite (default is still 12).
– Cleaned up description of Bleichenbacher/Klima attack defenses.
– Alerts MUST now be sent in many cases.
– After a certificate_request, if no certificates are available, clients now MUST send an empty certificate list.
TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement cipher suite.
– Added HMAC-SHA256 cipher suites.
Removed IDEA and DES cipher suites. They are now deprecated and will be documented in a separate document.
– Support for the SSLv2 backward-compatible hello is now a MAY, not a SHOULD, with sending it a SHOULD NOT. Support will probably become a SHOULD NOT in the future.
– Added limited “fall-through” to the presentation language to allow multiple case arms to have the same encoding.
– Added an Implementation Pitfalls sections
– The usual clarifications and editorial work.

TLS 1.3 vs TLS 1.2
– Allow cookies to be longer (*)
– Remove the “context” from EarlyDataIndication as it was undefined and nobody used it (*)
– Remove 0-RTT EncryptedExtensions and replace the ticket_age extension with an obfuscated version. Also necessitates a change to NewSessionTicket (*).
– Move the downgrade sentinel to the end of ServerHello.Random to accomodate tlsdate (*).
– Define ecdsa_sha1 (*).
– Allow resumption even after fatal alerts. This matches current practice.
– Remove non-closure warning alerts. Require treating unknown alerts as fatal.
– Make the rules for accepting 0-RTT less restrictive.
– Clarify 0-RTT backward-compatibility rules.
– Clarify how 0-RTT and PSK identities interact.
– Add a section describing the data limits for each cipher.
– Major editorial restructuring.
– Replace the Security Analysis section with a WIP draft.
– Allow server to send SupportedGroups.
– Remove 0-RTT client authentication
– Remove (EC)DHE 0-RTT.
– Flesh out 0-RTT PSK mode and shrink EarlyDataIndication
– Turn PSK-resumption response into an index to save room
– Move CertificateStatus to an extension
– Extra fields in NewSessionTicket.
– Restructure key schedule and add a resumption_context value.
– Require DH public keys and secrets to be zero-padded to the size of the group.
– Remove the redundant length fields in KeyShareEntry.
– Define a cookie field for HRR.
– Provide a list of the PSK cipher suites.
– Remove the ability for the ServerHello to have no extensions (this aligns the syntax with the text).
– Clarify that the server can send application data after its first flight (0.5 RTT data)
– Revise signature algorithm negotiation to group hash, signature algorithm, and curve together. This is backwards compatible.
– Make ticket lifetime mandatory and limit it to a week.
– Make the purpose strings lower-case. This matches how people are implementing for interop.
– Define exporters.
– Editorial cleanup
– Port the CFRG curves & signatures work from RFC4492bis.
– Remove sequence number and version from additional_data, which is now empty.
– Reorder values in HkdfLabel.
– Add support for version anti-downgrade mechanism.
– Update IANA considerations section and relax some of the policies.
– Unify authentication modes. Add post-handshake client authentication.
– Remove early_handshake content type. Terminate 0-RTT data with an alert.
– Reset sequence number upon key change (as proposed by Fournet et al.)
– Remove ClientCertificateTypes field from CertificateRequest and add extensions.
– Merge client and server key shares into a single extension.
– Change to RSA-PSS signatures for handshake messages.
– Remove support for DSA.
– Update key schedule per suggestions by Hugo, Hoeteck, and Bjoern Tackmann.
– Add support for per-record padding.
– Switch to encrypted record ContentType.
– Change HKDF labeling to include protocol version and value lengths.
– Shift the final decision to abort a handshake due to incompatible certificates to the client rather than having servers abort early.
– Deprecate SHA-1 with signatures.
– Add MTI algorithms.
– Remove support for weak and lesser used named curves.
– Remove support for MD5 and SHA-224 hashes with signatures.
– Update lists of available AEAD cipher suites and error alerts.
– Reduce maximum permitted record expansion for AEAD from 2048 to 256 octets.
– Require digital signatures even when a previous configuration is used.
– Merge EarlyDataIndication and KnownConfiguration.
– Change code point for server_configuration to avoid collision with server_hello_done.
– Relax certificate_list ordering requirement to match current practice.
– Integration of semi-ephemeral DH proposal.
– Add initial 0-RTT support.
– Remove resumption and replace with PSK + tickets.
– Move ClientKeyShare into an extension.
– Move to HKDF. – Prohibit RC4 negotiation for backwards compatibility.
– Freeze & deprecate record layer version field.
– Update format of signatures with context.
– Remove explicit IV. – Prohibit SSL negotiation for backwards compatibility.
– Fix which MS is used for exporters.
– Modify key computations to include session hash.
– Remove ChangeCipherSpec.
– Renumber the new handshake messages to be somewhat more consistent with existing convention and to remove a duplicate registration.
– Remove renegotiation.
– Remove point format negotiation.
– Remove GMT time.
– Merge in support for ECC from RFC 4492 but without explicit curves.
– Remove the unnecessary length field from the AD input to AEAD ciphers.
– Rename {Client,Server}KeyExchange to {Client,Server}KeyShare.
– Add an explicit HelloRetryRequest to reject the client’s.
– Increment version number.
– Rework handshake to provide 1-RTT mode.
– Remove custom DHE groups.
– Remove support for compression.
– Remove support for static RSA and DH key exchange.
– Remove support for non-AEAD ciphers.

Recommended reading resources

Everything about TLSv1.3
Taking a Closer Look at the SSL/TLS Handshake
TLS 1.3 Handshake: Taking a Closer Look