What Is SSL/TLS?

SSL/TLS is a pair of cryptographic protocols that encrypt data sent between a client and a server over a network. Transport Layer Security, abbreviated TLS, is the modern successor to the older Secure Sockets Layer, abbreviated SSL, and the two names are often written together as SSL/TLS. Every website address that begins with HTTPS relies on these protocols to keep data confidential and to confirm the identity of the server.

This article defines SSL/TLS, explains the TLS handshake that establishes a secure session, describes how certificates authenticate a server, separates HTTPS from plain HTTP, compares the SSL and TLS versions, and states what the protocol protects. The Internet Engineering Task Force, which publishes TLS 1.3 as RFC 8446, and the Transport Layer Security working group supply the references used here.

Each section answers one question about SSL/TLS and connects to the next. Readers learn why the handshake combines asymmetric and symmetric encryption, why SSL is deprecated, and what the padlock icon confirms.

What Is SSL/TLS?

SSL/TLS is a set of cryptographic protocols that secure data in transit between two communicating applications. Transport Layer Security is the current protocol, and Secure Sockets Layer is its deprecated predecessor. The Internet Engineering Task Force maintains TLS, with TLS 1.3 published as RFC 8446 in 2018.

SSL/TLS provides three guarantees: confidentiality through encryption, integrity through message authentication codes, and authentication through digital certificates. The protocol operates between the application layer and the transport layer, which lets protocols such as HTTP, SMTP, and IMAP run securely without redesign.

How Does the TLS Handshake Work?

The TLS handshake works by authenticating the server, agreeing on encryption parameters, and establishing a shared session key. The handshake runs before any application data transfers. The list below states the sequence for a TLS 1.3 connection.

1. Client hello sends the supported TLS versions, cipher suites, and a key share to the server.
2. Server hello returns the selected cipher suite, the server certificate, and its own key share.
3. Key agreement combines both key shares through an Ephemeral Diffie-Hellman exchange to derive a shared secret.
4. Finished messages confirm that both sides hold matching keys, after which encrypted application data flows.

TLS 1.3 completes this exchange in a single round trip, while TLS 1.2 required two. The handshake uses asymmetric cryptography to authenticate and exchange keys, then switches to faster symmetric encryption for the session. The mechanics of converting data with those keys appear in the explanation of how encryption transforms data using keys.

How Do Certificates Authenticate a Server?

Certificates authenticate a server by binding the server public key to a verified domain name through a signature from a Certificate Authority. During the handshake the server presents an X.509 certificate, and the client validates it before trusting the connection. The list below states the validation checks.

• Chain validation confirms a path from the server certificate to a trusted root authority preinstalled in the client.
• Hostname matching confirms the certificate subject matches the requested domain name.
• Validity dates confirm the current time falls within the certificate start and expiry dates.
• Signature verification confirms the Certificate Authority signature over the certificate data is intact.

A failure at any check produces a browser warning and blocks the session by default. The structure, fields, and issuance of these credentials appear in the explanation of how a digital certificate verifies a public key.

How Does SSL/TLS Combine Symmetric and Asymmetric Encryption?

SSL/TLS combines both methods by using asymmetric encryption to exchange a key and symmetric encryption to protect the data. Asymmetric operations are slow but solve key distribution, while symmetric operations are fast but require a shared key. The list below states the division of work.

• Asymmetric encryption authenticates the server and secures the key exchange during the handshake.
• Symmetric encryption protects the bulk application data once the session key is established.
• Session keys exist only for the duration of the connection and are discarded when it closes.

This hybrid design captures the security of asymmetric key exchange and the speed of symmetric bulk encryption. The full contrast between the two methods appears in the comparison of shared-key and public-key encryption methods.

What Is HTTPS and the Padlock Icon?

HTTPS is the HTTP protocol running over a TLS-encrypted connection. The S in HTTPS stands for secure and signals that TLS protects the data between browser and server.

The padlock icon in the address bar confirms that the connection uses a valid certificate and an encrypted session. The list below states what the padlock does and does not confirm.

• The padlock confirms the connection is encrypted and the certificate validates against a trusted authority.
• The padlock confirms the domain in the certificate matches the address shown.
• The padlock does not confirm the site is honest, because attackers can obtain valid certificates for their own domains.

A padlock proves transport security, not the trustworthiness of the operator. Browsers now mark plain HTTP pages as not secure, a change driven by widespread free certificate issuance from the Let’s Encrypt authority.

What Is the Difference Between SSL and TLS Versions?

SSL is deprecated, while TLS 1.2 and TLS 1.3 are the versions in active use. Each version corrected weaknesses in the one before it. The list below states the version history.

• SSL 2.0 and SSL 3.0 are deprecated, with SSL 3.0 disabled after the 2014 POODLE attack.
• TLS 1.0 and TLS 1.1 were deprecated by the Internet Engineering Task Force in 2021 through RFC 8996.
• TLS 1.2, published in 2008 as RFC 5246, remains widely supported and secure with modern cipher suites.
• TLS 1.3, published in 2018 as RFC 8446, removed obsolete algorithms and reduced the handshake to one round trip.

The term SSL persists in common use even though every secure connection now runs TLS. Certificates are still called SSL certificates for historical reasons, though they operate under TLS.

What Does SSL/TLS Protect?

SSL/TLS protects the confidentiality, integrity, and authenticity of data in transit. The protocol defends against interception and tampering between the two endpoints. The list below states the protections.

• Confidentiality prevents eavesdroppers from reading data through symmetric encryption of the session.
• Integrity detects tampering through message authentication codes attached to each record.
• Authentication confirms the server identity through certificate validation, and optionally the client identity.

SSL/TLS protects data only while it travels the network. It does not protect data stored on either endpoint, which depends on encryption at rest. The distinction between protecting data in motion and data held on a server appears in the explanation of how end-to-end encryption keeps content private across servers.

Why Do TLS Connections Sometimes Fail?

TLS connections fail when certificate validation, version negotiation, or cipher suite agreement cannot complete. A failed handshake blocks the connection rather than falling back to an insecure one. The list below states the common causes.

• Expired certificates fail date validation and trigger a browser security warning.
• Hostname mismatch occurs when the certificate subject does not match the requested domain.
• Untrusted issuer occurs when no path links the certificate to a trusted root authority.
• Protocol mismatch occurs when a client and server share no common supported TLS version.

Each failure protects the user by refusing an unverified or unencrypted session. Resolving the cause requires renewing the certificate, correcting the domain, or enabling a supported TLS version on the server.

What Is a Cipher Suite in TLS?

A cipher suite is a named combination of the algorithms a TLS connection uses for key exchange, encryption, and message authentication. The client and server agree on a single cipher suite during the handshake. The list below states the components a cipher suite defines.

• Key exchange determines how the session key is established, such as Ephemeral Diffie-Hellman.
• Authentication determines how the server proves identity, such as RSA or ECDSA signatures.
• Bulk cipher determines the symmetric algorithm that encrypts the data, such as AES in Galois/Counter Mode.
• Message authentication determines how integrity is verified, often integrated into authenticated encryption.

TLS 1.3 reduced the set of permitted cipher suites to a small group of modern, secure options and removed algorithms with known weaknesses. A server configured with only strong cipher suites resists downgrade attacks that exploit obsolete algorithms.

What Is Forward Secrecy in TLS?

Forward secrecy is a property where the compromise of a server private key does not expose past recorded sessions. TLS achieves this through ephemeral key exchange that generates a fresh key for each session. The list below states how forward secrecy protects recorded traffic.

• Ephemeral keys are generated per session and discarded when the connection closes.
• Recorded ciphertext stays unreadable because the session keys no longer exist after the session ends.
• Server key compromise exposes future sessions only, not traffic captured earlier.
• TLS 1.3 requires forward secrecy by mandating ephemeral key exchange for every connection.

Without forward secrecy, an attacker who records encrypted traffic and later steals the server key can decrypt the entire history. Mandatory ephemeral key exchange in TLS 1.3 removes that retroactive exposure.

Key Takeaways

• SSL/TLS encrypts data in transit and authenticates the server.
• TLS is the modern protocol, and SSL is its deprecated predecessor.
• The TLS handshake exchanges keys and establishes a symmetric session key.
• Certificates bind a server public key to a verified domain name.
• HTTPS is HTTP running over a TLS-encrypted connection.
• TLS 1.2 and TLS 1.3 are the secure versions in current use.
• SSL/TLS protects confidentiality, integrity, and authenticity in transit.

Last Thoughts on SSL/TLS

SSL/TLS secures data in transit by encrypting the session and authenticating the server through a certificate. The TLS handshake exchanges keys with asymmetric cryptography and then protects the data with faster symmetric encryption, a hybrid design that balances security and speed. SSL is deprecated, and TLS 1.2 and TLS 1.3 carry every modern secure connection, with TLS 1.3 reducing the handshake to a single round trip.

HTTPS is the visible result, and the padlock confirms transport security rather than operator honesty. SSL/TLS depends on digital certificates and encryption methods shared across the security cluster. The hub on cybersecurity fundamentals and protection layers situates SSL/TLS within the wider defense of network communication.