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

Availability of 5 GHz WLAN Channels in India under unlicensed band

Availability of 5 GHz WLAN Channels in India under unlicensed band  In India, Wireless Planning and Coordination Wing of Department of Telecom, under Ministry of Communication takes care of licensing of radio frequencies.  In the latest National Frequency allocation plan 2018 (, Government of India (GoI), exempted the licensing requirements of the following radio frequency ranges for wireless usage and a gazette notification has also published for this (  -- 1.  5150-5250 2. 5250-5350 3. 5470-5725 4. 5725-5875 References

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

Summary report of APNIC 55 (APRICOT 2023) Meeting held in Manila, Philippines

APNIC Logo The APNIC 55 meeting was held in Manila, Philippines from 20th Feb to 02nd March 2023. The meeting was hosted by PhNOG, The Philippine Network Operators Group (PhNOG) and supported by DOST- Advanced Science and Technology Institute. Every year, APNIC conferences are held twice, the first of each year is held in conjunction with APRICOT and the second one is a standalone conference. The last such meeting held in India was in 2012, APNIC 33 (which was in conjunction with APRICOT 2012).  APNIC 55 meeting was unique in multiple senses –  i. Firstly, because of the possibility of potential hijack [1] [2][3] of the APNIC Executive Council by Cloud Innovation Ltd. / Larus foundation / NRS, the same organizations which have dragged AFRINIC (RIR for African Continent) into the Mauritius supreme court and at one point nearly halted the AFRINIC operations by getting its bank accounts frozen (over 25 lawsuits have been filed against AFRINIC by Cloud Innovation Ltd.). Number