Bridge SSL
What is TLS? What happens before the padlock appears
TLS, Transport Layer Security, is the protocol that encrypts HTTPS and many other connections. Between clicking a link and seeing a padlock, two sides that have never met agree on how to talk, one of them proves who it is, and both derive keys nobody watching can reproduce. All of it happens before the first byte of your actual request is sent, and every failure on this site happens somewhere in that sequence.
- Stands for
- Transport Layer Security, the successor of SSL (Secure Sockets Layer)
- Provides
- confidentiality, integrity and authentication of the server
What TLS actually provides
TLS provides three properties, separated here because they fail separately.
Confidentiality — What travels between the two sides is unreadable to anybody in the path. This is the property people mean when they say encrypted, and it is the least interesting of the three, because it is also the easiest to have without the others.
Integrity — Nothing in transit can be altered without both sides noticing. Encryption alone would not give you this: an attacker unable to read a message can still corrupt it, and integrity is what makes that detectable rather than silent.
Authentication of the server — You are talking to the name you asked for, rather than to somebody who arranged to be in the middle. This is the property SSL/TLS certificates exist to establish, and it is the one that fails most visibly, because a browser refuses to continue without it.
Confidentiality without authentication is the dangerous combination: a perfectly encrypted connection to the wrong party protects that party's conversation with you.
The order of events
How does TLS work, step by step? A connection goes through four stages in this order, and knowing which one you are in narrows every diagnosis.
A connection opens — Ordinary networking, before any encryption exists. Failures here are network failures and look nothing like certificate problems.
The handshake runs — Both sides state what they support, agree on a version and a cipher suite, and establish keys. Nothing is encrypted at the start of this; by the end everything is.
The server presents its certificate — This happens inside the TLS handshake, not after it, and is listed apart because it fails apart. In TLS 1.3 the certificate already travels encrypted, since every handshake message after the ServerHello is [1]. The client checks it against the name it asked for, the dates it carries, and the chain behind it. This is where a browser warning comes from.
Application data flows — Your request finally leaves, encrypted. A failure at this stage is your application's, not the protocol's.
What the handshake settles
The handshake settles four questions in one exchange, which opens with the client’s first message, the ClientHello. It can also settle a fifth, which application protocol to speak, such as HTTP/2 or HTTP/1.1, through ALPN negotiation.
Which protocol version — Both sides support several and use the highest they share: TLS 1.3 is the current version, TLS 1.2 the one before it. Where they share none, the connection ends before anything else, which is one of the two ways a handshake fails for everyone at once.
Which cipher suite — The specific combination of algorithms used for the rest of the conversation, chosen from what both sides offer.
Which name is being requested — A single address can serve many names, so the client states which one it wants in the Server Name Indication extension (SNI, RFC 6066) early enough for the server to present the matching certificate. Without this, a server could only ever hold one certificate per address.
The keys themselves — Derived rather than transmitted, which is why somebody recording the exchange cannot reconstruct them afterwards from what they captured.
How TLS encrypts data
TLS encryption has two parts, and the handshake is only the first. The handshake authenticates the parties, negotiates the cryptographic parameters and establishes shared keying material; the record protocol then uses those parameters to protect the traffic (RFC 8446). The certificate serves the authentication step. It is how the server proves who it is, not what encrypts the traffic.
Once the keys exist, the record protocol divides the traffic into a series of records and protects each record independently with the traffic keys (RFC 8446). Every symmetric encryption algorithm that remains in TLS 1.3 is an Authenticated Encryption with Associated Data (AEAD) algorithm, which fits the pairing of confidentiality and integrity above. The algorithm in use is the one the cipher suites choice settled during the handshake.
Where a product says SSL encryption, or a site is encrypted with SSL, a connection that follows current IETF guidance is running TLS, so the same two parts apply (RFC 9325). TLS does not hide the length of the data it transmits, though endpoints can pad records to obscure lengths (RFC 8446). The exchange that produces the keys is laid out in the TLS handshake guide.
Which version is current: SSL and TLS compared
There is no current version of SSL. The latest version of the family is TLS 1.3, and every version that still carries the SSL name has been withdrawn by the IETF, the body that publishes the standard. The name survives in habit and in product names; a connection that follows current IETF guidance runs TLS 1.2 or TLS 1.3 [3].
| Version | Defined in | Status in IETF guidance |
|---|---|---|
| SSL 2.0 | Netscape specification, never an RFC | prohibited by RFC 6176 |
| SSL 3.0 | RFC 6101, published as a historical record | deprecated by RFC 7568: must not be used |
| TLS 1.0 | RFC 2246 | deprecated by RFC 8996: must not be used |
| TLS 1.1 | RFC 4346 | deprecated by RFC 8996: must not be used |
| TLS 1.2 | RFC 5246 | must be supported (RFC 9325) |
| TLS 1.3 | RFC 8446 | should be supported and preferred when both sides have it (RFC 9325) |
TLS 1.2 is not on its way out in these documents: the same guidance that forbids the four older versions requires TLS 1.2 alongside TLS 1.3.
Why the details keep changing
The protocol is not stable in the way its name suggests, and understanding why saves you from configuration advice that has quietly expired.
Cipher suites are removed when weaknesses are found, which means a list that was correct when somebody wrote it becomes a liability years later without anything on your server changing. Protocol versions are withdrawn by browsers on their own schedules, so a server that worked yesterday can start failing for visitors whose browser updated overnight.
The practical consequence is that configuration copied from an article can leave a server worse off than its default. Defaults are maintained by people tracking these changes; a block of text in a document is not.
Where each failure appears
The stage decides the symptom, which is why the same underlying fault produces different messages in different browsers.
- No shared version or suite, and the connection ends immediately for everybody.
- The certificate does not match, has expired, or cannot be traced to something trusted. These are the visible warnings, and they are sorted by code on SSL errors.
- The chain is incomplete, which fails for some clients and not others, because browsers are more forgiving than libraries. The mechanism is on certificate chains.
What this section covers
The protocol has more moving parts than this overview walks through: the handshake stage by stage, the differences between protocol versions, how to read a cipher suite, how keys are exchanged, how sessions are resumed and what that costs, how the application protocol is negotiated, what early data buys and risks, how downgrade attempts are refused, and what a client checks before accepting a certificate. Five have pages of their own: the handshake step by step, the protocol versions and which to enable, why compromising a key today does not expose yesterday's traffic, and the two linked above, on cipher suites and on ALPN.
What belongs elsewhere
Three boundaries, so this section stays about the protocol.
Certificates as objects belong to certificates: what one contains, what validation levels verify, and how the lifecycle runs. Here they appear only as something the handshake presents.
Browser errors belong to SSL errors, which sorts them by the code on screen. This section explains the mechanism behind a failure rather than helping you find yours.
Single-term definitions belong in the glossary. A page here explains how something works and what breaks; a glossary entry answers what a word means and sends you onward.
FAQ
The protocol and its names
What does TLS mean?
It stands for Transport Layer Security. It is the protocol that encrypts HTTPS connections and replaced SSL, its predecessor, whose name is still used informally. See SSL vs TLS.
Is TLS the same as SSL?
In practice the words are used interchangeably, and only one of them names a protocol still in use. SSL was the predecessor and is long withdrawn; TLS replaced it. The older name survives in product names, file names, and habit rather than in anything on the wire.
What is the current version of SSL?
There is none. The last SSL version, 3.0, is deprecated by RFC 7568, and the latest version of the protocol is TLS 1.3, defined in RFC 8446.
What is TLS 1.2?
The version before TLS 1.3, defined in RFC 5246. Current IETF guidance still requires implementations to support it, and to prefer TLS 1.3 when both sides have it (RFC 9325).
What is TLS encryption?
Encryption set up by the TLS protocol: during the handshake the two sides agree on algorithms and derive shared keys, then every message is encrypted and protected against changes. The certificate proves who the server is; it does not do the encrypting itself.
What is an SSL?
In everyday use, "an SSL" means an SSL/TLS certificate: the file a server presents during the handshake of every SSL/TLS connection to show that it holds the name being requested. The protocol behind the abbreviation is a different thing, and every version of it is withdrawn, as the version table above shows. What a certificate contains and how its lifecycle runs is covered on SSL certificates.
When something stops working
Does the padlock mean a site is safe?
No. It means the TLS connection is encrypted and the server proved it holds a certificate for that name. It says nothing about who obtained the certificate or what they intend, which is why a padlock on an unfamiliar site establishes far less than people assume.
What is negotiated during the TLS handshake?
The protocol version, the cipher suite, the name being requested, and the keys for the rest of the conversation. Both sides state what they support and the outcome is the best they share, which is why an old client and a modern server can fail to connect at all.
Why did my site work yesterday and fail today?
Usually because something outside your server changed: a browser withdrew support for a version or algorithm you were still offering, or a certificate reached its end date. Neither requires anybody to have touched your configuration, and both are invisible until they are not.
Should I copy a cipher suite configuration from a guide?
Preferably not. Such lists are correct when written and degrade quietly, because algorithms are withdrawn as weaknesses emerge and nothing updates a copied block. Current defaults are maintained by people tracking those changes; a paragraph in an article is maintained by nobody.
Security and connections
Is TLS secure?
TLS security rests on three properties of the channel: the server side is authenticated, data sent after the handshake is visible only to the endpoints, and an attacker cannot modify it without detection (RFC 8446). Secure TLS connections also depend on the version in use. RFC 9325 requires implementations to support TLS 1.2, recommends TLS 1.3, and forbids negotiating SSL 2.0, SSL 3.0, TLS 1.0 and TLS 1.1. The edges are stated as plainly as the properties: the data is visible to both endpoints, and TLS does not hide the length of what it transmits (RFC 8446).
Is SSL/TLS secure?
SSL and TLS security depends on the version the two sides negotiate and the algorithms they pick, which are cipher suites. IETF guidance tells implementations not to negotiate SSL 2.0, SSL 3.0, TLS 1.0 or TLS 1.1 (RFC 9325), and the same document records that the industry has seen several serious attacks on TLS, including attacks on widely used cipher suites and their modes of operation. TLS 1.3 removed static RSA and Diffie-Hellman cipher suites, so all of its public-key key exchange provides forward secrecy (RFC 8446). Which versions to enable is on TLS versions.
What is an SSL/TLS connection?
It is the encrypted channel two sides build on top of an ordinary network connection. TLS asks little of what lies underneath, only a reliable, in-order data stream, and higher-level protocols can layer on top of it transparently (RFC 8446). Encryption is in place once the handshake completes. Every SSL version is withdrawn, so a connection that follows current IETF guidance is a TLS connection, whatever name the product gives it (RFC 9325). Questions about how to connect with SSL are therefore questions about TLS, and a failure of SSL connectivity happens at one of the four stages in the order of events: that stage decides where to look.
Sources
RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3 — current version; handshake messages after the ServerHello are encrypted.
RFC 5246, The Transport Layer Security (TLS) Protocol Version 1.2.
RFC 9325 (BCP 195), Recommendations for Secure Use of TLS and DTLS — implementations must not negotiate SSL 2.0, SSL 3.0, TLS 1.0 or TLS 1.1, must support TLS 1.2, should support TLS 1.3.
RFC 6176 (SSL 2.0 prohibited), RFC 7568 (SSL 3.0 deprecated), RFC 8996 (TLS 1.0 and TLS 1.1 deprecated).
RFC 6066 (TLS extensions, including Server Name Indication); RFC 7301 (Application-Layer Protocol Negotiation).