Transport Layer Security (TLS) is a protocol that protects data exchanged between systems, using encryption and integrity checks with endpoint authentication.

HTTPS uses TLS to protect web traffic between a browser and a server. The connection helps keep customer information private in transit and lets the browser check that it is communicating with the expected server. These protections apply to the connection, with authentication depending on the protocol’s configuration.

How TLS protects a connection

During the handshake, the participants agree on supported cryptographic parameters and establish shared keying material. In a typical website connection, the server presents a certificate and proves control of the associated private key. The browser checks the certificate’s trust path and whether it matches the hostname it intended to reach.

The resulting traffic keys protect application data using symmetric cryptography. Integrity protection helps the receiver detect unauthorized changes in transit. Modern protocol designs also bind authentication to the handshake so an attacker cannot simply copy a public certificate and complete the exchange as that server.

TLS can authenticate the client as well as the server. This is commonly called mutual TLS, or mTLS, and is used in some service-to-service and enterprise integrations. Most ordinary customer website connections authenticate the server through TLS and handle customer sign-in separately.

TLS and the older SSL name

Secure Sockets Layer (SSL) was the predecessor to TLS. SSL versions are obsolete, but people still use phrases such as “SSL certificate” for certificates deployed with modern TLS. The certificate and the protocol version negotiated by a connection are separate things.

Services should use supported TLS implementations and current secure configurations. Continuing to accept obsolete protocols for compatibility can expose connections even if the same server also supports newer versions. Configuration needs to be checked at every endpoint that accepts customer traffic.

Where transport protection stops

TLS protects data between its endpoints. If a load balancer terminates the connection, the next connection to the application has its own security boundary. Encryption at rest is another separate decision after data reaches storage.

For example, a customer can submit identity documents through HTTPS to a legitimate portal. TLS protects that transfer, but the portal still needs to restrict which account can view the uploaded files. It also needs to protect the documents after receipt.

A fraudulent website can obtain a valid certificate for a domain it controls. A browser’s secure-connection indicator therefore does not establish that the business is legitimate or that sharing credentials with it is safe.

Frequently asked questions

Are SSL and TLS the same protocol?

No. TLS succeeded SSL. The older name persists in everyday language, but obsolete SSL protocols should not be used for modern secure connections.

Does HTTPS authenticate the customer?

Ordinary HTTPS authenticates the server and protects the connection. Customer authentication usually happens separately, unless a client-authentication mechanism such as mTLS is configured.

Does TLS protect data after it is stored?

No. TLS protects data in transit between endpoints. Stored data needs appropriate access controls and any encryption required by the storage design.

Related: API Security · Man-in-the-Middle Attack · Authentication · Machine Identity · Phishing · Data Breach