Skip to content

SSL / TLS

Summary
  • SSL (Secure Sockets Layer) is the deprecated original name for this protocol. TLS (Transport Layer Security) is its modern successor and the name actually in use today — every version of SSL itself is now considered insecure and disabled everywhere.1
  • TLS protects three things at once: confidentiality (nobody else can read the traffic), integrity (nobody can silently tamper with it), and authentication (you're actually talking to who you think you are).
  • TLS runs on top of TCP; its UDP counterpart is DTLS (Datagram TLS) — relevant for protocols that don't use TCP.

Think of TLS as:

"A sealed, tamper-evident, signature-verified envelope wrapped around whatever you're actually sending — the postal service (TCP) still handles delivery, but nobody along the way can read it, alter it, or convince you it came from someone else."

SSL vs. TLS: Same Job, Different Name

SSL and TLS aren't two competing protocols — TLS is SSL's successor, just renamed partway through its life when the IETF took over standardization from Netscape. Every SSL version, and the two oldest TLS versions, are now formally deprecated:1

Version Released Status
SSL 2.0 1995 Deprecated 2011 (RFC 6176)2
SSL 3.0 1996 Deprecated 2015 (RFC 7568) — broken by the POODLE attack3
TLS 1.0 1999 Deprecated 2021 (RFC 8996)4
TLS 1.1 2006 Deprecated 2021 (RFC 8996)4
TLS 1.2 2008 Current — still the most widely deployed version
TLS 1.3 2018 Current — the recommended target for new deployments (RFC 8446)5

Table 1. SSL/TLS Version History

"SSL certificate" is a misnomer that stuck

Almost everyone still says "SSL certificate," "SSL port," and "install an SSL cert" — but functionally, what's actually running today is TLS. The terminology just never fully caught up with the protocol rename.

What TLS Actually Does

Three separate guarantees, all bundled into one handshake:

  • Confidentiality — traffic is encrypted with a symmetric cipher (e.g., AES-GCM, ChaCha20-Poly1305), so an eavesdropper sees only ciphertext.
  • Integrity — an AEAD (Authenticated Encryption with Additional Data) construction or a separate MAC detects any tampering; a modified packet simply fails to decrypt/verify.
  • Authentication — the server (and, in mTLS, the client too) proves its identity using a certificate, preventing a man-in-the-middle from silently impersonating either side.

The TLS Handshake

Before any application data flows, client and server negotiate a shared symmetric key and confirm each other's identity:

  1. ClientHello — the client proposes a TLS version, a list of cipher suites it supports, and a random value
  2. ServerHello — the server picks a version and cipher suite, sends its own random value, and its certificate
  3. Key exchange — both sides derive the same symmetric session key (in modern TLS, via ephemeral Diffie-Hellman, giving forward secrecy — a compromised key later can't decrypt past sessions)
  4. Finished — both sides confirm the handshake wasn't tampered with, and switch to encrypted application data

TLS 1.3 cut this down significantly

TLS 1.2 needed two full round trips before any application data could flow. TLS 1.3 restructured the handshake to need only one round trip, and added an optional 0-RTT resumption mode for reconnecting to a server you've already talked to — sending application data on the very first flight. It also removed a long list of legacy, since-broken options (RC4, CBC-mode ciphers, static RSA key exchange, compression) rather than just deprecating them.5

Certificates & Chain of Trust

A certificate (X.509 format) cryptographically binds an identity (a domain name, typically) to a public key, and is itself signed by a Certificate Authority (CA). A client trusts a server's certificate if it can trace an unbroken chain of signatures from that certificate up to a root CA already in its trust store.

Self-Signed CA-Signed
Trust Only trusted if manually added to the client's trust store Trusted automatically by anyone whose trust store already includes that CA
Cost Free Often free (e.g., Let's Encrypt) to paid, depending on the CA
Typical use Internal/private networks, device provisioning, testing Anything public-facing

Table 2. Self-Signed vs. CA-Signed Certificates

Mutual TLS (mTLS)

In standard TLS, only the server presents a certificate — the client just verifies it. Mutual TLS (mTLS) flips that around too: the client also presents its own certificate, so the server cryptographically verifies the client's identity as part of the handshake, not through some separate application-layer login step.

This matters especially for machine-to-machine and IoT scenarios: an mTLS client certificate can be a device's identity — no separate username/password/API key needed, and a compromised device's certificate can simply be revoked.

DTLS: TLS for UDP

TLS assumes an underlying reliable, ordered stream — which is exactly what TCP provides and exactly what UDP doesn't. DTLS (Datagram Transport Layer Security) adapts TLS's same security guarantees to work over UDP, adding explicit sequence numbers and tolerance for packet loss/reordering that TLS itself doesn't need.

TLS DTLS
Transport TCP UDP
Handles packet loss/reordering Not needed — TCP already guarantees this Yes, built into the protocol
Current versions 1.2, 1.3 1.2 (1.0 deprecated, no 1.1 exists)
Typical use Web traffic, most application-layer protocols over TCP UDP-based protocols needing the same security guarantees

Table 3. TLS vs. DTLS

TLS for Constrained IoT Devices

Full TLS — certificate chains, RSA/ECDSA signature verification, a handful of round trips — can be genuinely expensive for a small microcontroller with limited RAM, flash, and battery. A few things exist specifically to help:

  • RFC 7925 defines a TLS/DTLS profile specifically for IoT — a recommended, narrowed-down subset of ciphers, extensions, and certificate handling suited to constrained devices, rather than the full generality of TLS as used on the web.6
  • PSK (Pre-Shared Key) mode skips the certificate exchange entirely — both sides already share a secret key out-of-band (provisioned at manufacturing time, for example), which avoids the RAM and CPU cost of asymmetric certificate verification altogether.
  • TLS 1.3's 0-RTT resumption matters more on constrained links than it might seem — fewer round trips is a direct battery-life and airtime win on a slow or high-latency radio link.
  • Embedded-focused TLS libraries — most constrained devices don't run OpenSSL; they run something purpose-built for a small footprint, like mbedTLS or wolfSSL, both explicitly designed for microcontroller-class RAM/flash budgets.7

Testing TLS from the Command Line

# Check what TLS version and cipher a server negotiates
openssl s_client -connect example.com:443 -tls1_3

# Fetch and inspect a server's certificate
openssl s_client -connect example.com:443 -showcerts

Useful Resources

  1. SSL Dragon. (n.d.). SSL and TLS versions: Complete history (1994–2026). https://www.ssldragon.com/blog/history-of-ssl-tls-versions/ ↩↩

  2. IETF. (2011). Prohibiting Secure Sockets Layer (SSL) version 2.0 (RFC 6176). https://www.rfc-editor.org/rfc/rfc6176 ↩

  3. IETF. (2015). Deprecating Secure Sockets Layer version 3.0 (RFC 7568). https://www.rfc-editor.org/rfc/rfc7568 ↩

  4. Moriarty, K., & Farrell, S. (2021). Deprecating TLS 1.0 and TLS 1.1 (RFC 8996). IETF. https://www.rfc-editor.org/rfc/rfc8996 ↩↩

  5. Rescorla, E. (2018). The Transport Layer Security (TLS) Protocol Version 1.3 (RFC 8446). IETF. https://www.rfc-editor.org/rfc/rfc8446 ↩↩

  6. Tschofenig, H., & Fossati, T. (2016). Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) profiles for the Internet of Things (RFC 7925). IETF. https://www.rfc-editor.org/rfc/rfc7925 ↩

  7. wolfSSL. (n.d.). SSL/TLS protocol comparisons. https://www.wolfssl.com/docs/ssltls-protocol-comparisons/ ↩