SSL/TLS Explained: Securing Data in Transit
How SSL/TLS encrypts communication between clients and servers, the handshake process, and what modern configurations look like.
Last updated Apr 7, 2026Current
Continue your mission
How SSL/TLS encrypts communication between clients and servers, the handshake process, and what modern configurations look like.
SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are cryptographic protocols that encrypt communication between two parties, typically a web browser and a server. TLS is the modern successor to SSL. All versions of SSL are deprecated and insecure. When people say "SSL" today, they usually mean TLS, but the terminology persists.
The current recommended version is TLS 1.3, released in 2018. TLS 1.2 is still acceptable but should be configured carefully. TLS 1.0 and 1.1 are deprecated and should be disabled.
Before encrypted communication begins, the client and server must agree on how to encrypt. This negotiation is called the TLS handshake.
In TLS 1.3, the handshake completes in just one round trip (1-RTT), which is faster than TLS 1.2's two round trips. Here is the simplified flow:
A TLS certificate binds a domain name to a public key. Certificate authorities (CAs) are trusted third parties that issue these certificates after verifying domain ownership. Your browser and operating system ship with a pre-loaded list of trusted CAs.
When you see the padlock icon in your browser, it means the server presented a valid certificate signed by a trusted CA, and the connection is encrypted. It does not mean the website is safe or legitimate. Attackers can and do obtain valid certificates for phishing domains.
A cipher suite defines the algorithms used for key exchange, encryption, and message authentication. A modern TLS 1.3 configuration uses:
ECDHE for key exchange (provides forward secrecy), AES-256-GCM or ChaCha20-Poly1305 for symmetric encryption, and SHA-384 for hashing.
Forward secrecy is a critical property. It means that even if the server's private key is compromised in the future, past session traffic cannot be decrypted because each session used unique ephemeral keys.
Avoid cipher suites that use RSA key exchange (no forward secrecy), CBC mode (vulnerable to padding oracle attacks in older implementations), or SHA-1 (collision attacks demonstrated).
Not enforcing HTTPS everywhere. Use HTTP Strict Transport Security (HSTS) headers to tell browsers to always connect via HTTPS. This prevents downgrade attacks where an attacker strips TLS from the connection.
Using self-signed certificates in production. Self-signed certs trigger browser warnings and train users to click through security alerts, which undermines your security culture.
Neglecting certificate expiration. Let's Encrypt certificates expire every 90 days. Automate renewal with certbot or your cloud provider's certificate manager. Expired certificates cause outages and erode trust.
Not checking the full certificate chain. A valid leaf certificate is not enough if the intermediate CA certificate is missing or expired. Test with tools like SSL Labs' free scanner.
Run your domains through Qualys SSL Labs (ssllabs.com/ssltest) to get a letter grade and detailed report. Aim for an A or A+ rating. The scanner checks your TLS versions, cipher suite order, certificate chain, key strength, and known vulnerabilities like Heartbleed or ROBOT.
CDA Theater missions that address topics covered in this article.
Cryptographic technique that encrypts data while preserving its original format and length, enabling protection without breaking legacy system compatibility.
Guide to HTTP/2 security covering binary framing, HPACK compression attacks, rapid reset vulnerability, stream multiplexing risks, and mitigation strategies.
Explanation of Certificate Transparency framework, covering log servers, Signed Certificate Timestamps, monitoring capabilities, and detection of fraudulent certificates.
Written by CDA Wiki Team
Found an issue? Help improve this article.