Skip to main content
Fundamentals

Understanding SSL/TLS Protocols

Explore TLS handshakes, cryptographic mechanisms, protocol history, and the security properties behind HTTPS.

CertOne4 min read

Online shopping, banking, and everyday browsing all depend on protecting data in transit. TLS provides the cryptographic foundation for HTTPS. This article explains how the protocol works, how it evolved, and the security properties it provides.

1. What Are SSL and TLS?​

SSL (Secure Sockets Layer) and its successor TLS (Transport Layer Security) are protocols for securing network communications. TLS protects application traffic with encryption, authentication, and integrity checks.

1. The Relationship Between SSL and TLS​

Netscape developed SSL in the 1990s. The IETF published TLS 1.0 in 1999 as a successor to SSL 3.0. TLS has replaced SSL technically, although "SSL" remains common in product names and terms such as "SSL certificate".

The TLS version history includes:

  • TLS 1.0 (1999): Deprecated
  • TLS 1.1 (2006): Deprecated
  • TLS 1.2 (2008): Broadly supported
  • TLS 1.3 (2018): Significant security and performance improvements

2. What TLS Provides​

TLS provides three main security properties:

Confidentiality: Encryption protects application data from passive eavesdropping.

Authentication: Certificate validation helps the client verify that it is communicating with the intended server.

Integrity: Authentication tags or message authentication codes detect changes to protected traffic.

2. How TLS Works​

1. The Handshake​

A TLS connection starts with a handshake. The following is a simplified overview; message order and key exchange details depend on the TLS version and negotiated algorithms.

Step 1: The client initiates the connection

  • The client sends a ClientHello message.
  • It advertises supported versions, cipher suites, and other parameters.

Step 2: The server responds

  • The server sends a ServerHello message.
  • It selects a mutually supported protocol version and cipher suite.
  • The server also supplies its certificate and the messages required by the selected handshake.

Step 3: The client validates the certificate

  • The client validates the server certificate.
  • It checks the chain against its trusted certificate authorities.
  • It verifies validity dates, hostname matching, and other applicable requirements.

Step 4: The peers establish shared secrets

  • Modern certificate-based handshakes typically use ephemeral Diffie-Hellman key agreement.
  • Legacy RSA key transport instead encrypted a client-generated pre-master secret with the server's RSA public key; TLS 1.3 removed this mode.
  • Both peers derive traffic keys from the negotiated shared secret and handshake context.

Step 5: Protected communication begins

  • Both peers use the negotiated algorithms and derived traffic keys.
  • Application data is transmitted with confidentiality and integrity protection.

2. Cryptographic Mechanisms​

TLS combines several cryptographic techniques:

Symmetric encryption: Efficiently protects application data. Common algorithms include AES and ChaCha20, used with authentication mechanisms.

Public-key cryptography: Supports authentication and key establishment. RSA and ECDSA can provide signatures; ECDH provides key agreement.

Hash functions: Algorithms such as SHA-256 and SHA-384 support transcript hashing, key derivation, and authentication constructions.

3. The Role of Certificates​

Certificates bind an identity to a public key. Important fields include:

  • Public key: Used to verify the server's authentication proof; legacy RSA key transport also used it to encrypt the pre-master secret.
  • Domain names: The hostnames covered by the certificate
  • Issuer: The certificate authority that signed the certificate
  • Validity: the period during which the certificate is valid
  • Digital signature: the issuer's signature over the certificate contents

3. Protocol History​

1. SSL 1.0 - 3.0​

  • SSL 1.0: Never publicly released
  • SSL 2.0 (1995): The first public SSL version, later found to have serious weaknesses
  • SSL 3.0 (1996): Improved on SSL 2.0, but later deprecated following attacks including POODLE

2. TLS 1.0 - 1.2​

  • TLS 1.0 (1999): Based on SSL 3.0; now deprecated
  • TLS 1.1 (2006): Addressed some earlier weaknesses; now deprecated
  • TLS 1.2 (2008): Introduced important cryptographic improvements and remains broadly supported

3. TLS 1.3​

TLS 1.3 was published in 2018 and introduced substantial changes:

Performance improvements:

  • A typical full handshake takes one round trip instead of two.
  • Optional 0-RTT early data can reduce resumption latency but requires replay-risk controls.

Security improvements:

  • Removes obsolete algorithms and handshake modes.
  • Certificate-based handshakes use ephemeral key exchange for forward secrecy.
  • Simplifies the handshake and reduces legacy complexity.

Simpler cipher suites:

  • The base TLS 1.3 specification defines five AEAD-based cipher suites.
  • Key exchange and authentication are negotiated separately from cipher suites.

4. Security Properties and Supporting Mechanisms​

1. Perfect Forward Secrecy​

Forward secrecy protects previously recorded sessions if the server's long-term private key is later compromised. Ephemeral key exchange derives separate session secrets rather than relying solely on that long-term key.

2. Certificate Transparency​

Certificate Transparency provides public, append-only logs of submitted certificates. Monitoring these logs helps domain owners and others detect unexpected or incorrectly issued certificates.

3. HSTS（HTTP Strict Transport Security）​

HSTS tells browsers to use HTTPS for a host after learning its policy, helping prevent downgrade attacks. Preloading can extend this protection to the first connection.

4. OCSP Stapling​

Where supported by the issuing CA, OCSP stapling lets the server include a signed certificate status response in the TLS handshake, reducing separate client OCSP requests and their privacy impact.

5. Select Suitable TLS Versions​

1. A Practical Baseline​

  • Minimum version: TLS 1.2 for modern browser-facing services
  • Preferred version: TLS 1.3 where both peers support it
  • Cipher suites: Prefer secure suites and forward-secret key exchange.

2. Compatibility Considerations​

When enabling TLS 1.3, account for your client population:

  • Older clients may not support TLS 1.3.
  • Supporting both TLS 1.2 and TLS 1.3 can provide compatibility without enabling deprecated versions.

6. Ongoing TLS Development​

1. Post-quantum cryptography​

Large-scale quantum computers could threaten established public-key algorithms. Post-quantum cryptography aims to provide alternatives designed to resist such attacks.

2. Stricter Certificate Validation​

Certificate ecosystems evolve toward tighter validation requirements and shorter certificate lifetimes, increasing the importance of reliable automation.

3. Automated Certificate Management​

ACME automates certificate issuance and renewal, reducing the operational effort required to deploy HTTPS.

Conclusion​

TLS protects network communications through encryption, authentication, and integrity checks. Successive protocol versions have improved its design and removed obsolete mechanisms.

Administrators and developers should understand the handshake, select suitable protocol versions and algorithms, and validate deployed certificates. Ongoing protocol and cryptographic developments make regular configuration reviews essential.

Deploy HTTPS carefully and maintain it consistently to provide secure, reliable services.