Definition: what SSL/TLS encryption does

SSL is the older name for the protocol; in practice, most people mean TLS. TLS encryption is the way a client (like a web browser) and a server create a protected communication channel so that data in transit can’t be read or easily altered by outsiders.

TLS typically provides three things together: confidentiality (encryption), integrity (tampering detection), and authentication (using certificates to help confirm who you’re talking to).

A simple model of the TLS handshake

Think of the TLS handshake as a short “agreement” phase before any application data is sent. In broad strokes:

  1. The client asks for a secure session. It sends what protocol versions and cryptographic options it supports.

  2. The server presents credentials. The server sends a certificate that includes its public key and identifies the server via a trusted certificate chain.

  3. The parties agree on shared secrets. Using the server’s public key (and other handshake inputs), the client and server derive the session keys that will encrypt the data for this connection.

  4. Finished checks confirm the handshake. Both sides verify that they derived the keys correctly and that the handshake wasn’t tampered with.

After this, the connection moves to sending application data over the encrypted channel.

What gets encrypted (and what doesn’t)

TLS encrypts the content being sent between client and server—such as HTTP request and response bodies—so that a passive observer can’t read it. Depending on how the connection is used, metadata can still be visible to some extent (for example, traffic patterns), and TLS does not automatically guarantee that the endpoints themselves are trustworthy.

Also, “encryption in transit” doesn’t replace other controls. For example, if a site is misconfigured or a certificate is incorrectly validated, attackers may still be able to interfere with what you think you’re connecting to.

Key differences and important limits

A few limits help set expectations:

  • Authentication is not optional. TLS relies on validating certificates (directly or via a chain to a trusted root). If a client skips validation or if trust stores are mismanaged, the protection can be weakened.

  • TLS is about the connection, not the content’s origin. TLS can protect data while it travels, but it can’t ensure that the server is the one you intended if validation fails or is bypassed.

  • Protocol and configuration matter. While TLS is a standard approach, different versions and cipher choices can affect security. Modern configurations generally aim to disable weaker legacy options.

Because there are many TLS deployments and client/server configurations, the exact handshake details can vary across versions (for example, TLS 1.2 vs TLS 1.3). Still, the core idea remains: authenticate, agree on keys, then encrypt data.

Practical checks you can do

You can verify that TLS encryption is active and that authentication is being handled correctly:

  • Check the site’s certificate status in your browser (commonly via the lock icon or certificate details).
  • Look for certificate validity and matching identity (the certificate should correspond to the domain you requested).
  • Prefer HTTPS and avoid interstitial warnings related to certificate errors.

If you’re troubleshooting, focus on whether the certificate validates and whether the connection negotiates a modern TLS version with strong cryptographic settings.