TLS(Transport Layer Security) protocol version outdated

Transport Layer Security (TLS) – which is now deprecated by the Internet Engineering Task Force (IETF) – are cryptographic protocols that provide communications security over a computer network. Several versions of the protocols find widespread use in applications such as web browsing, email, instant messaging, and voice over IP (VoIP). Websites can use TLS to secure all communications between their servers and web browsers.

Since applications can communicate either with or without TLS (or SSL), it is necessary for the client to indicate to the server the setup of a TLS connection. One of the primary ways of achieving this is to use a different port number for TLS connections, for example, port 443 for HTTPS. Another mechanism is for the client to make a protocol-specific request to the server to switch the connection to TLS; for instance, by creating a STARTTLS request when using the mail and news protocols. Once the client and server have agreed to use TLS, they negotiate a stateful connection by using a handshaking procedure. The protocols use a handshake with an asymmetric cipher to establish not only cipher settings but also a session-specific shared key with which further communication is encrypted using a symmetric cipher. During this handshake, the client and server agree on various parameters used to establish the connection’s security:

• The handshake begins when a client connects to a TLS-enabled server requesting a secure connection and the client presents a list of supported cipher suites (ciphers and hash functions).
• From this list, the server picks a cipher and hash function that it also supports and notifies the client of the decision.
• The server usually then provides identification in the form of a digital certificate. The certificate contains the server name, the trusted certificate authority (CA) that vouches for the authenticity of the certificate, and the server’s public encryption key.
• The client confirms the validity of the certificate before proceeding.
• To generate the session keys used for the secure connection, the client either:
  1. encrypts a random number with the server’s public key and sends the result to the server (which only the server should be able to decrypt with its private key); both parties then use the random number to generate a unique session key for subsequent encryption and decryption of data during the session
  2. uses Diffie–Hellman key exchange to securely create a random and unique session key for encryption and decryption that has the additional property of forward secrecy: if the server’s private key is disclosed in future, it cannot be used to decrypt the current session, even if the session is intercepted and recorded by a third party.

TLS 1.0

TLS 1.0 outdated version This version is vulnerable to many implementations and it fails to shield against attacks such as BEAST and POODLE.This version of TLS can be easily breached by the attackers. 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.

The PCI Council suggests that organisations migrate from TLS 1.0 to TLS 1.1 or higher before June 30, 2018

TLS 1.1

TLS 1.1 outdated version.The pseudo random function in TLS is based on a combination on a MD5 and SHA-1.The attacker can easily break these function and in return can cause severe damage to the server. 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:

• Added protection against cipher-block chaining (CBC) attacks.
  • The implicit initialization vector (IV) was replaced with an explicit IV.
  • Change in handling of padding errors.
• Support for IANA registration of parameters.

TLS 1.2

LS 1.2 was defined in RFC 5246 in August 2008. It is based on the earlier TLS 1.1 specification. Major differences include:

The MD5-SHA-1 combination in the pseudorandom function (PRF) was replaced with SHA-256, with an option to use cipher suite specified PRFs. The MD5-SHA-1 combination in the finished message hash was replaced with SHA-256, with an option to use cipher suite specific hash algorithms. However, the size of the mixture in the completed message must still be at least 96 bits. The MD5-SHA-1 combination in the digitally signed element was replaced with a single hash negotiated during handshake, which defaults to SHA-1. Enhancement in the client’s and server’s ability to specify which hashes and signature algorithms they accept. Expansion of support for authenticated encryption ciphers, used mainly for Galois/Counter Mode (GCM) and CCM mode of Advanced Encryption Standard (AES) encryption. TLS Extensions definition and AES cipher suites were added. All TLS versions were further refined in RFC 6176 in March 2011, removing their backward compatibility with SSL such that TLS sessions never negotiate the use of Secure Sockets Layer (SSL) version 2.0.

TLS 1.3

As of 21 March 2018, TLS 1.3 is an Internet Draft proposed to Internet Standard It is based on the earlier TLS 1.2 specification. Major differences from TLS 1.2 include:

• Separating key agreement and authentication algorithms from the cipher suites
• Removing support for weak and lesser-used named elliptic curves
• Removing support for MD5 and SHA-224 cryptographic hash function
• Requiring digital signatures even when a previous configuration is used
• Integrating HDKDF and the semi-ephemeral DH proposal
• Replacing resumption with PSK and tickets
• Supporting 1-RTT handshakes and initial support for 0-RTT
• Mandating perfect forward secrecy,, by means of using ephemeral keys during the (EC)DH key agreement
• Dropping support for many insecure or obsolete features including compression, renegotiation, non-AEAD ciphers, non-PFS key exchange (among which static RSA and static DH key exchanges), custom DHE groups, EC point format negotiation, Change Cipher Spec protocol, Hello message UNIX time, and the length field AD input to AEAD ciphers
• Prohibiting SSL or RC4 negotiation for backwards compatibility
• Integrating use of session hash
• Deprecating use of the record layer version number and freezing the number for improved backwards compatibility
• Moving some security-related algorithm details from an appendix to the specification and relegating Client KeyShare to an appendix Addition of the Chacha20 stream cipher with the Poly1305 message authentication code
• Addition of the Ed25519 and Ed448 digital signature algorithms
• Addition of the x25519 and x448 key exchange protocols

Impact

The vulnerability include

• Man-in-the-middle attacks

Mitigation / Precaution

• To eliminate the possibility of exploitation of TSL, install the updated TSL packages
• Update TLS to latest version

Written by

Rejah Rehim

Co-founder, Director