Skip to main content

Transport Layer Security (TLS) and Secure Sockets Layer (SSL)

Transport Layer Security (TLS) is a successor of Secure Sockets Layer (SSL) and its a cryptographic protocol used for establishing an encrypted link between a Server and a Client over a public network.
They use X.509 certificates and hence asymmetric cryptography to authenticate the certificate holder to its clients, and to negotiate a symmetric session key. This session key is used to encrypt the data communication between client and server. This allows message confidentiality and authenticity.

TLS is widely used in applications like:-

i.   Email
ii.  Web Broswing
iii. VoIP

Because of the use of X.509 certificates,  CAs and PKI infrastructure are necessary to verify the certificates and for the establishment of chain-of trust.

TLS is an Internet Engineering Task Force (IETF) standards track protocol, first defined in 1999 and updated in RFC 5246 (August 2008) and RFC 6176 (March 2011). It is based on the earlier SSL specifications (1994, 1995, 1996) developed by Netscape Communications.

History and present development 

SSL 1.0, 2.0 and 3.0

Netscape developed the original SSL protocols. Version 1.0 was never publicly released because of serious security flaws in the protocol; version 2.0, released in February 1995, contained a number of security flaws which ultimately led to the design of SSL version 3. SSL version 3.0, released in 1996, represented a complete redesign of the protocol.

Newer versions of SSL/TLS are based on SSL 3.0. The 1996 draft of SSL 3.0 was published by IETF as a historical document in RFC 6101 . Dr. Taher Elgamal, chief scientist at Netscape Communications from 1995 to 1998, is recognised as the "father of SSL".

As of 2014 the 3.0 version of SSL is considered insecure as it is vulnerable to the POODLE attack that affects all block ciphers in SSL; and RC4, the only non-block cipher supported by SSL 3.0, is also feasibly broken as used in SSL 3.0.

SSL 2.0 is deprecated in RFC 6176.
SSL 3.0 is deprecated in RFC 7568.


Private Communications Technology (PCT) 1.0 was a protocol developed by Microsoft in the mid-1990s. PCT was designed to address security flaws in version 2.0 of Netscape's Secure Sockets Layer protocol and to force Netscape to hand control of the then-proprietary SSL protocol to an open standards body. PCT has since been superseded by SSLv3 and Transport Layer Security. For a while it was still supported by Internet Explorer, but PCT 1.0 has been disabled since IE 5. It is still found in IIS and in the Windows operating system libraries, although in Windows Server 2003 it is disabled by default.

TLS 1.0

TLS 1.0 was first defined in RFC 2246 in January 1999 as an upgrade of SSL Version 3.0, and written by Christopher Allen and Tim Dierks of Consensus Development.
As stated in the RFC, "the differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough to preclude interoperability between TLS 1.0 and SSL 3.0". TLS 1.0 does include a means by which a TLS implementation can downgrade the connection to SSL 3.0, thus weakening security.

TLS 1.1

TLS 1.1 was defined in RFC 4346 in April 2006. It is an update from TLS version 1.0.

Significant differences in this version include:
i. Added protection against cipher-block chaining (CBC) attacks.
     a. The implicit initialisation vector (IV) was replaced with an explicit IV.
     b. Change in handling of padding errors.
ii. Support for IANA registration of parameters.

TLS 1.2

TLS 1.2 was defined in RFC 5246 in August 2008. It is based on the earlier TLS 1.1 specification. Many major changes has been done in TLS 1.2.

All TLS versions were further refined in RFC 6176 in March 2011 removing their backward compatibility with SSL such that TLS sessions will never negotiate the use of Secure Sockets Layer (SSL) version 2.0.

TLS 1.3 (draft)

As of September 2015, TLS 1.3 is a working draft, and details are provisional and incomplete. It is based on the earlier TLS 1.2 specification. Major differences from TLS 1.2 include:

  • Removed support for weak and lesser used named curves
  • Removed support for MD5 and SHA-224 hashes with signatures
  • Required digital signatures even when a previous configuration is used
  • Integration of HKDF and the semi-ephemeral DH proposal
  • Replacement of resumption with PSK and tickets
  • Relegation of ClientKeyShare to an appendix
  • Support for 1-RTT handshakes and initial support for 0-RTT
  • Dropped support for many insecure or obsolete features including, compression, renegotiation, non-AEAD ciphers, static RSA and DH key exchange, custom DHE groups, point format negotiation, Change Cipher Spec protocol, Hello message UNIX time, and the length field AD input to AEAD ciphers
  • Prohibition of SSL or RC4 negotiation for backwards compatibility
  • Integrated usage of session hash
  • The record layer version number has been frozen and deprecated for improved backwards compatibility
  • Movement of some security related algorithm details from an appendix to the specification

For a details list of browser supporting TLS and SSL, please refer the below link -

Popular posts from this blog

Flaw in ServerKeyExchange messages of TLS Protocol

Here we will discuss the flaw in the ServerKeyExchange messages of the TLS protocol which caused the Logjam attack over TLS while using Diffie-Hellman Key Exchange. Before SSLv3, we don't use to authenticate the ServerKeyExchange messages where server negotiates with client regarding usage of cipersuite and parameters. From onwards SSLv3, TLS send the signed message where it mention about parameters it will use but remain silent over ciphersuite. Or in other words, signed portion contains parameters but not contain information about ciphersuite the server will going to use. Now just to remind you, the difference between DH and DH-EXPORT is the size of parameters only. So how to use this flaw - If the server supports DH-EXPORT, an attacker (Men-in-the-Middle) can edit the negotiation sent by the client (even if client doesn't support DH-EXPORT), and replace the list of client supported ciphersuite with DH-EXPORT only. The server will in turn send back a

Identity PSK ( iPSK)

With the evolution of IoT (Internet of Things), devices that connect wirelessly have increased many folds. From webcams, Smartwatches, fitness bands, firestick, Alexa, Google Home, and many more.., everything is going wireless for connectivity and so does the security threat. The main concern with IoT devices is the unavailability of the full wireless protocol stack (and in the majority of devices, support of 802.1x is not available). So, previously we only have the WPA-PSK option for connecting the IoT devices.  In WPA*-PSK (WPA or WPA2) WLAN, a Pre-Shared Key (PSK) is configured and distributed to all the clients that connect to the WLAN. This leads to PSK leakage, and it can be accessible to unauthorized users (due to the nature of common PSK across all the devices).  Therefore, there was a need to provision unique PSK or Multiple PSK per SSID. Identity-PSKs are unique pre-shared keys created for clients/groups on the same WLAN. Features of iPSK:-   1.Unique PSK for individual Cli