SSL/TLS Protocol Overview

SSL/TLS Protocol Overview

(1) Protocol overview

• SSL (Secure Sockets Layer) is now-deprecated predecessor of TLS (Transport Layer Security).
  • A standard security technology for establishing an encrypted connection between a client and a server, typically:
    • > A browser and a web server
    • > A mail client and a mail server
• SSL/TLS is a security protocol that provides communications security over the network.
  • It doesn’t fit neatly into any single layer of the OSI model.
  • It runs on top of TCP, which would imply that it is above OSI layer 4.
  • Some security vendor, put this as it can be thought of as layer 5 and 6.
    • > Layer 5: For its session management via handshake messages
    • > Layer 6: For its encryption/decryption
• SSL/TLS allows client-server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.
  • Data privacy (confidentiality): The connection is private/secure because symmetric cryptography key is used to encrypt the data transmitted. This is to prevent eavesdropping.
  • Data integrity authentication: The connection is reliable because each message transmitted includes a message integrity check using a message authentication code. This is to prevent data tampering.
  • Peer authentication: The identity of the communicating parties can be authenticated using public-key cryptography. This is to prevent message forgery.
  • Secure key exchange: The symmetric cryptography key negotiation is secured by cryptographic key exchange algorithm and the assymetric cryptography keys. This is to tie all things together.
• Since most applications can communicate either with or without SSL/TLS, it is necessary for the client to indicate to the server the setup of a SSL/TLS connection. Examples:
  • HTTP: client need to add ‘s’ (https) in the begining URL, and default TCP port is 443 (instead of 80).
  • IMAP/POP3/SMTP: client need to make a “STARTTLS” request, or use separate SSL/TLS port (for IMAP-IMAPS is 993, instead of 143).

(2) Protocol history and development

SSL (Secure Sockets Layer)

• SSL 1.0, was first developed in 1994 by Netscape but was never publicly released because it was riddled with serious security flaws.
• SSL 2.0 released in February 1995, wasn’t a whole lot better, so just a year later SSL 3.0 was released. it had serious security flaws and was deprecated in 2011 by RFC 6176.
  • The use of MD5 is no longer acceptable
  • Handshake messages are not protected
  • Message integrity and message encryption use the same key
  • Sessions can be easily terminated (TCP FIN Attack)
• SSL 3.0 released in 1996, RFC 6101. It represented a complete redesign of the protocol. It also had many security flaws and was deprecated in June 2015 by RFC 7568.
  • Vulnerable to the POODLE attack (for CBC, Cipher Block Chaining)
  • RC4 (non-block cipher or stream cipher), exhibits serious exploit biases in the keystream, where able to recover repeatedly encrypted plaintexts

TLS (Transport Layer Security)

• TLS 1.0 released in January 1999 as an upgrade of SSL 3.0, RFC 2246. TLS 1.0 includes a means of ability to downgrade the connection to SSL 3.0, thus weakening security. The PCI Council suggested that organizations migrate from TLS 1.0 to TLS 1.1 or higher before 30 June 2018.
  • Vulnerable to the BEAST attack Certificate
  • Vulnerable to Klima attack
• TLS 1.1 released in April 2006. It is an update from TLS version 1.0, RFC 4346. Major differences 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
• In October 2018, Apple, Google, Microsoft, and Mozilla jointly announced they would deprecate TLS 1.0 and 1.1 in March 2020. The IETF is also planning to officially deprecate both protocols.
  • They don’t support modern cryptographic algorithms, and they contain security vulnerabilities
  • The MD5 and SHA-1 hashing algorithms are vulnerable to Collision attack
  • Vulnerable to attacks: POODLE, CRIME
• TLS 1.2 released in August 2008, RFC 5246. 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 hash in the finished 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.
• TLS 1.3 released in August 2018, RFC 8446. Major differences include:
  • Separating key agreement and authentication algorithms from the cipher suites
  • Removing support for weak and less-used named elliptic curves
  • Removing support for MD5 and SHA-224 cryptographic hash functions
  • Requiring digital signatures even when a previous configuration is used
  • Integrating HKDF 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 are 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 ClientKeyShare to an appendix
    Adding the ChaCha20 stream cipher with the Poly1305 message authentication code
  • Adding the Ed25519 and Ed448 digital signature algorithms
  • Adding the x25519 and x448 key exchange protocols
  • Adds support for sending multiple OCSP responses
  • Encrypts all handshake messages after the ServerHello