Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are often mentioned together, especially when people refer to an “SSL certificate” or “SSL inspection.” They are not interchangeable protocol versions. SSL is the obsolete predecessor; properly configured TLS is what protects most contemporary HTTPS connections. The distinction matters when an administrator evaluates an endpoint, audits an old integration, or investigates why two systems cannot establish a secure connection.
TLS establishes an authenticated, encrypted channel between communicating endpoints. It is used by web traffic, email transport and many other protocols, but the security of a connection depends on the negotiated version, cryptographic parameters, certificate validation and the system terminating TLS. A padlock icon cannot establish that an entire application, identity system or downstream service is secure.
Why SSL was replaced rather than merely renamed
SSL emerged when commercial use of the web made passive interception and server impersonation serious concerns. Its historical handshake, record protection and certificate model shaped subsequent secure transport protocols. The protocol family also carried design constraints that became untenable as attacks and implementation experience accumulated. SSL 2.0 and SSL 3.0 are not acceptable choices for a new secure service; “enable SSL” in an old product interface must not be interpreted as permission to permit those versions.
TLS 1.0 and TLS 1.1 were standardized successors, but they are themselves obsolete. The IETF formally deprecated both in RFC 8996. Among the reasons are their reliance on older cryptographic mechanisms and the operational risk of maintaining additional protocol versions. When documenting a historical deployment, name the actual version. Calling every historical encrypted session “TLS 1.3” would be as misleading as treating an SSL-era configuration as a modern best practice.
Current configuration discussions generally focus on TLS 1.3 and, where still necessary, a carefully restricted TLS 1.2 configuration. TLS 1.2 is not simply “insecure” by definition; its practical strength depends heavily on which suites, signature algorithms and key-exchange options are enabled. Conversely, TLS 1.3 is not a guarantee that a certificate is valid or that an application is resistant to authentication and authorization defects.
What a secure TLS connection actually establishes
A useful mental model separates the handshake from protected application traffic. The client proposes supported protocol parameters. The peers agree on a common version and suitable cryptographic options, authenticate the server or both parties according to the deployment, and derive secrets from which traffic keys are obtained. Once the handshake succeeds, records carry encrypted and integrity-protected application data. Details differ materially between TLS 1.2 and TLS 1.3; an old description of an RSA-encrypted “session key” is not an accurate general description of modern TLS.
The three central properties are confidentiality, integrity and authentication, but each has a scope. Confidentiality aims to keep transport records unreadable to parties without the traffic keys. Integrity means unauthorized modification of protected records is detected. Authentication binds a cryptographic handshake to an identity represented by a verified certificate or another explicitly configured mechanism. The protocol does not determine whether the authenticated server is trustworthy with the information it receives.
Modern suites use symmetric authenticated encryption for data in transit. For example, AES-GCM and ChaCha20-Poly1305 provide confidentiality and record authenticity together; this differs from casually describing encryption alone as a guarantee of integrity. The encryption techniques article develops the distinction among symmetric primitives, authenticated-encryption modes and obsolete approaches. Choosing a cipher suite is not the same as deciding which certificate an endpoint should trust.
Public-key cryptography has a different role: it supports authentication and aspects of key establishment. Certificates carry public keys associated with identities, while ephemeral Diffie–Hellman exchanges can establish fresh shared secrets. This is why the separate treatment of asymmetric encryption matters: public-key operations are not simply a slower replacement for bulk encryption, nor are they inherently “more secure” in every use case.
Handshake and key exchange: the TLS 1.2 versus TLS 1.3 difference
TLS 1.2 supports several key-exchange families, and the selected configuration determines whether it delivers forward secrecy. Legacy RSA key transport is not equivalent to ephemeral Diffie–Hellman. An administrator retaining TLS 1.2 for compatibility should examine the permitted suites and certificate-signature algorithms, not just verify that the version label reads “1.2.” TLS 1.3 removes many historical options and simplifies the protocol so implementations have fewer weak combinations to negotiate.
In a conventional full TLS 1.3 handshake, the client and server exchange parameters and key shares, derive handshake secrets, authenticate the endpoint as required, and establish traffic keys using a defined key schedule. The IETF specification, RFC 8446, describes supported key exchanges, the HKDF-based key schedule, authenticated encryption and transcript binding. The simplification is substantive; simply replacing a version string in a document does not explain what changed.
Forward secrecy means compromise of a long-term authentication key does not, by itself, expose previously recorded sessions that used appropriate ephemeral key establishment. It does not mean an active endpoint compromise is harmless, and it does not protect records when session keys themselves are stolen. Resumed sessions and pre-shared-key choices introduce additional considerations. Investigators should distinguish a stolen certificate private key from stolen traffic secrets and from an attacker already controlling the server.
TLS 1.3 also permits optional 0-RTT early data in resumed connections, but early data has weaker properties than ordinary post-handshake traffic. In particular, the protocol cannot guarantee non-replay of 0-RTT data across connections. A payment, account mutation or other non-idempotent request should not be treated as safe merely because it arrives encrypted in early data. The application and server deployment must implement a suitable replay policy, or disable early data for such operations.
Certificates, identity checks and what HTTPS does not prove
In common browser-to-website HTTPS, a server presents a certificate and the client checks whether its chain leads to an accepted trust anchor, whether its identity matches the requested hostname, whether the certificate is within its validity period and whether applicable policy checks succeed. Implementations may use additional controls such as revocation information, but the details and failure behavior depend on the client, configuration and ecosystem. A signed certificate is not automatic evidence that the website’s content or business practices are reliable.
TLS can also authenticate clients when a service requests and validates client certificates, a pattern common in some business-to-business and service-to-service systems. Even mutual TLS does not decide what an authenticated client is allowed to do. Application authorization, account lifecycle, token handling and audit controls remain separate requirements. Similarly, a reverse proxy can terminate TLS successfully while sending unencrypted or separately protected traffic to a backend: the network path, not the browser icon, defines the complete exposure.
Certificate expiration is only one cause of failures. A missing intermediate certificate, hostname mismatch, untrusted private certificate authority, unsupported signature algorithm or incorrect server name indication can prevent a connection. The right response is to inspect the actual validation failure. Disabling certificate verification to “make it work” replaces the diagnostic problem with a potentially exploitable impersonation vulnerability.
Attacks and misconfigurations that still matter
Protocol versions fail differently from implementations. Older SSL and TLS designs exposed weaknesses in cipher negotiation, CBC processing and downgrade handling; applications have also shipped certificate-verification bugs or insecure fallback logic. A clear discussion of cryptographic attacks helps distinguish weaknesses in cryptographic primitives from attacks against the handshake, the endpoint, the certificate system or a poorly configured application.
A downgrade concern arises when an attacker manipulates compatibility behavior to get peers to accept an older or weaker protocol than they otherwise would. Modern implementations and deployment policies reduce these opportunities, but the basic operational advice is to disable obsolete versions and avoid permissive fallback. Old versions should not remain enabled simply because a security scanner reports that the server supports TLS at all.
HTTPS also does not eliminate cross-site scripting, credential theft from an endpoint, fraudulent login interfaces, compromised certificate authorities or leaks after the server decrypts a request. The TLS channel has a clearly bounded security purpose. Calling a site “fully secure” because it presents HTTPS confuses transport protection with the security of accounts, code and data handling.
Choosing TLS 1.3 and handling necessary TLS 1.2 compatibility
Prefer TLS 1.3 where both endpoints support it. Retain TLS 1.2 only where an explicit compatibility or policy requirement justifies it, using modern recommended suites, valid certificates and supported library versions. Review the actual published client and server configuration guidance applicable to the environment. NIST’s SP 800-52 Revision 2 is a useful published reference for federal use cases; note that NIST opened a further review in May 2026, so its future revisions should not be confused with already-final requirements.
Inventory the systems that terminate or originate TLS: web servers, CDNs, API gateways, load balancers, service meshes, mail gateways, monitoring agents and embedded clients. Record offered protocol versions and suites, certificate identities and expiration, trust-store ownership, backend encryption and session-resumption behavior. When an old client requires TLS 1.0, TLS 1.1 or SSL, treat that as a migration or isolation issue rather than silently weakening an internet-facing service for everyone.
Testing must include both successful and failed handshakes. Confirm that a valid supported client connects, that deprecated versions are rejected, and that a client rejects a wrong hostname or untrusted issuer. An “A” score from a third-party scanner can be useful supporting evidence, but it does not establish that every origin, internal service or credential-checking path is protected.
Troubleshooting a failed handshake without lowering security
Start with the actual endpoint and the layer reporting failure. A browser message about certificate trust is different from a protocol-version alert, and both differ from a transport timeout before negotiation begins. Server logs, client diagnostics and packet captures can show whether the peers agree on a TLS version, whether their certificate and signature choices are compatible, and where the handshake stops.
Check the chain and hostname before changing trust settings. If the certificate is valid but a client is unusually old, verify what versions and algorithms the client genuinely supports. If two modern systems still cannot negotiate, examine disabled suites, server-name routing, certificate-key types, signature algorithms and middleboxes. Do not respond to a failed negotiation by permitting every obsolete cipher and protocol version globally.
For service-to-service environments, also distinguish authentication success from application health. A successful TLS handshake followed by HTTP 403 indicates a different class of failure from a cryptographic handshake abort. Likewise, an upstream proxy that talks TLS to the browser but plain HTTP to its origin may be operationally correct only under an explicitly assessed and protected trust boundary, not as a universal security claim.
The practical decision: SSL terminology, TLS implementation
Use “SSL” when discussing the historical protocols or quoting legacy product terminology; use a specific TLS version when assessing modern transport. A valid certificate is necessary in many deployments but is not sufficient to establish a complete security posture. Version support, actual key exchange, identity verification, application policy and the boundaries of TLS termination determine what users are protected from.
For a new deployment, the decision is not between turning on SSL and turning on TLS. It is how to deploy a supported TLS stack, verify the intended identities, protect every relevant segment of the connection and test failures without downgrading security. For legacy systems, the task is to document the real dependency and retire or isolate it safely while preserving the operational requirements that made it difficult to replace.
