TLS/SSL is the cryptographic protocol that encrypts data moving between two systems — a browser and a web server, a CI runner and a package registry, or one microservice and another. Without it, credentials, session tokens, and source code travel in plaintext and can be read or altered by anyone positioned on the network path. "SSL" (Secure Sockets Layer) is the older, deprecated name; "TLS" (Transport Layer Security) is its successor and the version actually in use today. The distinction matters for security teams because outdated protocol versions and unpatched implementations — not the concept of encryption itself — are what attackers exploit. Heartbleed (CVE-2014-0160) alone exposed private keys and session data on an estimated 500,000 X.509 certificates in April 2014 because of a single buffer over-read in OpenSSL 1.0.1. This glossary entry breaks down how TLS/SSL works, where it fails, and how to keep it out of your CVE backlog.
What is TLS/SSL?
TLS/SSL is a protocol suite that provides encryption, authentication, and integrity checking for data in transit over a network. SSL was created by Netscape, with SSL 2.0 shipping in 1995 and SSL 3.0 following in 1996 after SSL 1.0 was scrapped internally for security flaws before release. The IETF took over standardization in 1999, renaming the protocol TLS and publishing TLS 1.0 as RFC 2246. Subsequent versions — TLS 1.1 (RFC 4346, 2006), TLS 1.2 (RFC 5246, 2008), and TLS 1.3 (RFC 8446, August 2018) — progressively removed weak ciphers, sped up the handshake, and closed cryptographic gaps. Every major protocol that needs confidentiality rides on top of TLS: HTTPS, SMTPS, gRPC over TLS, and the mutual TLS (mTLS) used between microservices in a service mesh.
How does a TLS handshake actually work?
A TLS handshake works by having the client and server agree on a cipher suite, verify identity via a certificate, and derive a shared session key, all before any application data is sent. In TLS 1.2, the sequence is: the client sends a ClientHello listing supported cipher suites and a random value; the server responds with a ServerHello, its X.509 certificate, and (for ephemeral key exchange) a signed key share; the client verifies the certificate chain against a trusted root CA, generates a pre-master secret, encrypts it with the server's public key, and both sides derive symmetric session keys from it. TLS 1.3 cuts this to a single round trip by combining the key exchange into the initial hello messages and mandates forward-secret (ephemeral Diffie-Hellman) key exchange, which TLS 1.2 only supported optionally. That single change is why a TLS 1.3 handshake averages roughly half the latency of TLS 1.2 on a typical 100ms RTT connection.
Why are SSL 3.0 and early TLS versions considered insecure?
SSL 3.0 and TLS 1.0/1.1 are considered insecure because each has a publicly exploited cryptographic weakness with an assigned CVE, not just theoretical risk. SSL 3.0 fell to POODLE (CVE-2014-3566) in October 2014, a padding-oracle attack that lets a man-in-the-middle decrypt one byte of ciphertext per roughly 256 requests. TLS 1.0 inherited the same CBC-mode padding weakness and was additionally hit by BEAST (CVE-2011-3389) in 2011, which recovered HTTPS session cookies via chosen-plaintext injection. PCI DSS 3.2 required all payment processors to disable TLS 1.0 by June 30, 2018, and the IETF formally deprecated both TLS 1.0 and TLS 1.1 in RFC 8996, published March 2021, instructing implementers to remove support entirely rather than merely discourage it. Any server or library still negotiating these versions today is running a protocol its own standards body has retired.
What's the actual difference between TLS and SSL?
The actual difference is version lineage and current validity: SSL is the deprecated branch (versions 1.0–3.0), and TLS is the maintained branch (versions 1.0–1.3) that replaced it starting in 1999. In practice "SSL" survives mostly as legacy terminology — SSL certificates, SSL/TLS termination, an "SSL" checkbox in a load balancer config — even though the certificate and connection are almost certainly negotiating TLS 1.2 or 1.3 under the hood. This naming drift causes real inventory problems: a scanner or engineer searching a codebase for "SSL" will miss configuration flags explicitly named tls_version or min_tls, and vice versa, letting a misconfigured minimum version (e.g., a load balancer still accepting TLS 1.0 for backward compatibility) go undetected during an audit.
Where does TLS/SSL risk show up in the software supply chain?
TLS/SSL risk in the software supply chain shows up primarily as outdated crypto libraries bundled inside container images, transitive dependencies, and vendored code, not as a single misconfigured server. Heartbleed (CVE-2014-0160), disclosed April 7, 2014, is the canonical example: a missing bounds check in OpenSSL's heartbeat extension let an attacker read up to 64KB of process memory per request, exposing private keys, session tokens, and credentials on servers running OpenSSL 1.0.1 through 1.0.1f. Netcraft estimated roughly 17% of the internet's HTTPS servers were vulnerable at disclosure, and the bug persisted for years afterward inside Docker base images and firmware that nobody rebuilt. A decade later, the same pattern repeats: an SBOM audit of a typical container fleet regularly turns up OpenSSL 1.0.2 (end-of-life since January 2020) or 1.1.1 (end-of-life September 2023) still baked into images pulled from public registries, invisible to a source-code scan because the vulnerable binary was never in the application's own repo.
How should security teams verify TLS configuration, not just library versions?
Security teams should verify TLS configuration by testing the negotiated protocol version, cipher suite, and certificate chain against a live endpoint, because a patched library can still be configured to accept insecure defaults. Tools like openssl s_client -connect host:443 -tls1_1 or Qualys SSL Labs' server test reveal whether a server actually negotiates TLS 1.0/1.1, offers export-grade or RC4 ciphers, or serves an expired/self-signed certificate — none of which a dependency scan or SBOM diff will catch, since they're runtime configuration, not code. NIST SP 800-52 Rev. 2 (August 2019) sets the baseline most federal and regulated environments now audit against: TLS 1.2 minimum, TLS 1.3 preferred, and explicit prohibition of SSL 2.0/3.0 and RC4. Pairing a configuration scan with dependency and SBOM data closes the loop between "the library is patched" and "the endpoint is actually safe."
How Safeguard Helps
Safeguard closes the gap between knowing a TLS/SSL vulnerability exists and knowing whether it's actually exploitable in your environment. Our SBOM generation and ingest pipeline catalogs every OpenSSL, BoringSSL, and language-native TLS library across your containers and dependency trees — including versions buried in base images that source scanning alone would miss. Reachability analysis then determines whether the vulnerable TLS code path (like OpenSSL's heartbeat handler in CVE-2014-0160) is actually invoked by your application, so teams triage the handful of instances that matter instead of every occurrence in the SBOM. Griffin AI correlates that reachability data with exploit intelligence to prioritize which TLS findings need same-day attention, and Safeguard's auto-fix PRs open the version bump or config change directly against the affected manifest or Dockerfile — turning a protocol-level finding into a merged fix without a manual triage cycle.