Top 10 SSL/TLS Questions Every Security Pro Must Master

Top 10 Frequently Asked SSL/TLS Questions

Whether you are preparing for a security certification, a technical interview, or simply want to deepen your understanding of network security, SSL/TLS is an unavoidable core topic. This article selects ten commonly examined SSL/TLS questions and provides detailed explanations to help you build a comprehensive understanding.

1. What is the difference between SSL and TLS?

Brief answer:

SSL (Secure Sockets Layer) was developed by Netscape in 1995 and is now completely deprecated.

TLS (Transport Layer Security) is the successor to SSL and the modern standard for secure communication.

TLS 1.0 (1999) is essentially an upgrade of SSL 3.0.

All SSL versions (SSL 2.0 and SSL 3.0) are considered insecure and have been abandoned.

Current best practice is to use TLS 1.2 or TLS 1.3.

Version evolution:

SSL 2.0 (1995) → SSL 3.0 (1996) → TLS 1.0 (1999) → TLS 1.1 (2006) → TLS 1.2 (2008) → TLS 1.3 (2018)

Although technically the term "TLS" should be used, many documents still refer to "SSL certificates" which are actually TLS certificates.

2. How does the TLS handshake work?

Brief answer: The TLS handshake is the process by which a client and server establish a secure connection, negotiate security parameters, verify the server’s identity, and generate a shared secret key.

TLS 1.2 handshake flow:

Client                                 Server
  | --------- ClientHello ----------> | (supported TLS version, cipher suites, random)
  | <-------- ServerHello --------- | (chosen TLS version, cipher suite, random)
  | <-------- Certificate --------- | (server's certificate with public key)
  | <---- ServerKeyExchange (opt) | (parameters for DHE/ECDHE if used)
  | <---- CertificateRequest (opt) | (request client certificate)
  | <-------- ServerHelloDone ----- |
  | ---- ClientKeyExchange ------> | (pre‑master secret encrypted with server public key)
  | ---- CertificateVerify (opt) -> | (if client certificate provided)
  | ---- ChangeCipherSpec ------> | (notify switch to encrypted traffic)
  | ---- Finished --------------> | (encrypted handshake hash)
  | <---- ChangeCipherSpec ------- |
  | <---- Finished --------------- |
  | ========== Application Data =========== |

TLS 1.3 simplified handshake:

Client                                 Server
  | -------- ClientHello ---------> | (supported parameters + key share)
  | <------- ServerHello --------- | (chosen parameters + key share)
  | <------- EncryptedExtensions - |
  | <------- Certificate --------- |
  | <------- CertificateVerify ---- |
  | <------- Finished ------------ |
  | -------- Finished ----------> |
  | ========== Application Data =========== |

3. What are the components of an SSL/TLS certificate and how is it verified?

Brief answer: An SSL/TLS certificate is a digital proof of a server’s identity signed by a trusted Certificate Authority (CA).

Certificate mainly contains:

Domain name (CN) or Subject Alternative Name (SAN)

Server public key

Issuer information

Validity period

Digital signature (created with CA private key)

Serial number

Certificate type / usage

Verification process:

The browser receives the server’s certificate.

It checks that the certificate is not expired and that the domain matches.

It uses the CA’s public key to verify the certificate’s signature.

If necessary, it follows the chain of intermediate certificates up to a trusted root.

It checks the revocation status (CRL or OCSP).

If all checks pass, the server is trusted.

4. What is a Public Key Infrastructure (PKI) and how does it support SSL/TLS?

Brief answer: PKI is a comprehensive system that supports public‑key encryption and digital certificates, providing the trust framework for SSL/TLS.

Main PKI components:

Certificate Authority (CA) – issues certificates.

Registration Authority (RA) – verifies requestor identity.

Certificate database – stores certificate information.

Certificate store – securely holds certificates.

Revocation system (CRL/OCSP).

How PKI supports SSL/TLS:

Provides identity verification (certificate validation).

Establishes a trust chain from root CA to the end‑entity certificate.

Manages the lifecycle of keys (creation, distribution, revocation).

Enables asymmetric encryption.

5. What are the most common SSL/TLS vulnerabilities?

Brief answer: Historical SSL/TLS vulnerabilities include Heartbleed, POODLE, BEAST, and many others that exploit protocol design flaws or implementation bugs.

Major SSL/TLS vulnerabilities:

Vulnerability

Year

Impact

Root Cause

Heartbleed

2014

OpenSSL

Buffer overflow allowing memory leakage (including private keys)

POODLE

2014

SSL 3.0

Padding oracle attack enabling decryption of HTTPS sessions

BEAST

2011

TLS 1.0

CBC‑mode block chaining attack

CRIME/BREACH

2012/2013

TLS compression

Exploits HTTP compression to leak encrypted content

Logjam

2015

DHE key exchange

Forces downgrade to weak 512‑bit DH parameters

FREAK

2015

Export‑grade RSA

Forces use of weak "export" RSA keys

Lucky 13

2013

CBC mode

Timing‑based padding oracle attack

Sweet32

2016

Block cipher

Birthday attack on 64‑bit block ciphers

ROBOT

2017

RSA padding

Re‑creates the classic Bleichenbacher attack

Zombie POODLE / GOLDENDOODLE

2019

TLS 1.2

Variant of CBC‑padding attacks

Mitigation measures:

Keep TLS libraries and software up to date.

Disable old protocol versions (SSL 2.0/3.0, TLS 1.0/1.1).

Configure secure cipher suites.

Deploy security headers such as HSTS.

Regularly scan for TLS vulnerabilities.

6. What is Perfect Forward Secrecy (PFS) and why is it important?

Brief answer: PFS is a cryptographic property that ensures past encrypted communications remain confidential even if the long‑term private key is later compromised.

Technical implementation:

Uses temporary (ephemeral) keys for each session.

Typically achieved with DHE (Diffie‑Hellman) or ECDHE (Elliptic‑Curve Diffie‑Hellman).

Temporary keys are discarded after the session ends.

Even if the server’s private key is leaked, historical session keys cannot be recovered.

Why it matters:

Prevents "store now, decrypt later" attacks.

Limits the impact of a single point of failure.

Protects historical traffic from future key compromises.

Defends against mass surveillance.

7. What are the main cryptographic algorithms used in SSL/TLS?

Brief answer: SSL/TLS combines multiple algorithms into cipher suites, covering key exchange, authentication, symmetric encryption, and message authentication.

TLS cipher suite components:

Key exchange algorithms: RSA, DHE/ECDHE, PSK.

Authentication algorithms: RSA, ECDSA, DSA.

Symmetric encryption algorithms: AES‑GCM (preferred), AES‑CBC (TLS 1.2 and earlier), ChaCha20‑Poly1305 (mobile‑friendly).

Message authentication codes (MAC): HMAC‑SHA256, HMAC‑SHA1 (deprecated), Poly1305 (used with ChaCha20).

TLS 1.3 supported cipher suites:

TLS_AES_256_GCM_SHA384

TLS_CHACHA20_POLY1305_SHA256

TLS_AES_128_GCM_SHA256

TLS_AES_128_CCM_8_SHA256 (optional)

TLS_AES_128_CCM_SHA256 (optional)

8. What is certificate revocation and what are the main methods?

Brief answer: Certificate revocation announces that a certificate is invalid before its natural expiration, typically due to private‑key compromise, domain ownership change, or CA policy updates.

Main revocation mechanisms:

Certificate Revocation List (CRL): CA publishes a list of revoked certificates.

Pros: simple, batch status.

Cons: can be large, not always up‑to‑date, privacy concerns.

Online Certificate Status Protocol (OCSP): Real‑time query for a single certificate’s status.

Pros: timely, efficient.

Cons: adds latency, privacy issues, availability risk.

OCSP Stapling: Server periodically obtains an OCSP response and attaches it to the TLS handshake.

Pros: no extra latency, reduces CA load, improves privacy.

Cons: requires server support.

Certificate Transparency (CT): Public logs that help detect fraudulent certificates, supplementing traditional revocation.

Revocation workflow example:

1. Certificate holder reports private‑key compromise.
2. CA adds the certificate to its CRL and updates OCSP.
3. Browser checks revocation status:
   a. Download CRL and search for the serial number, or
   b. Send OCSP request, or
   c. Verify OCSP stapled response from the server.
4. If revoked, the browser aborts the connection.

9. What is SSL/TLS certificate pinning and how is it implemented?

Brief answer: Pinning is a security technique that restricts a client to accept only a predefined certificate or public key, protecting against man‑in‑the‑middle attacks even if a valid CA‑signed certificate is presented.

Main implementation methods:

Public‑key pinning: Trust only a specific server public key (allows certificate renewal as long as the key stays the same).

Certificate pinning: Trust a specific certificate (more strict; requires client update when the certificate changes).

Certificate‑chain pinning: Trust a particular CA or intermediate certificate, permitting end‑entity certificate changes.

Technical approaches:

HTTP Public Key Pinning (HPKP) – now deprecated due to usability risks.

Expect‑CT header – requires certificates to appear in public CT logs.

Mobile app pinning – hard‑code certificate or public‑key hashes in the app (e.g., Android Network Security Configuration, iOS App Transport Security).

DNS‑based Authentication of Named Entities (DANE) – uses DNSSEC‑protected TLSA records to specify allowed certificates or CAs.

10. What improvements does TLS 1.3 bring compared to earlier versions?

Brief answer: TLS 1.3 (published 2018) is a major upgrade focusing on security, privacy, and performance. It removes many flawed features, simplifies the handshake, and enforces forward secrecy.

Key improvements:

Removal of insecure algorithms: All static RSA and DH key exchanges, CBC‑mode ciphers, RC4, DES, 3DES, MD5, and SHA‑1 are eliminated.

Simplified handshake: Reduces round‑trips to 1‑RTT (or optional 0‑RTT), merges early messages.

Enhanced privacy: Handshake encryption, encrypted SNI (ESNI/ECH), and less clear‑text metadata.

Mandatory forward secrecy: All cipher suites require (EC)DHE key exchange.

Simplified cipher suites: Only a handful of AEAD suites remain (e.g., TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256).

TLS 1.2 vs TLS 1.3 handshake comparison:

TLS 1.2 (2‑RTT):
C → ClientHello → S
S ← ServerHello, Certificate, ServerKeyExchange, ServerHelloDone ← C
C → ClientKeyExchange, ChangeCipherSpec, Finished → S
S ← ChangeCipherSpec, Finished ← C

TLS 1.3 (1‑RTT):
C → ClientHello(+key_share) → S
S ← ServerHello, EncryptedExtensions, Certificate, Finished ← C
C → Finished → S

Common exam points:

Understanding 0‑RTT mode and its security considerations.

Reasons for removing static RSA key exchange.

Changes in session resumption (PSK vs session tickets).

Configuration steps to enable TLS 1.3 on servers.

Summary: Core Takeaways for SSL/TLS

SSL is obsolete; modern systems use TLS 1.2 or TLS 1.3.

The TLS handshake establishes mutual authentication and a shared secret.

Certificates are the foundation of identity verification.

PKI provides the trust framework for certificate validation.

Historical vulnerabilities (Heartbleed, POODLE, etc.) illustrate the need for timely updates.

Perfect forward secrecy protects past sessions from future key compromises.

Cipher suites combine key exchange, authentication, encryption, and MAC algorithms.

Revocation mechanisms (CRL, OCSP, stapling, CT) manage certificate lifecycle.

Certificate pinning adds an extra layer of protection beyond the CA model.

TLS 1.3 represents the evolution toward a more secure, private, and efficient protocol.

Understanding these ten topics provides a comprehensive view of SSL/TLS, useful for exams, security architecture design, and vulnerability assessment.