Every time you see https and a small padlock at the start of a web address, a quiet piece of cryptography is at work protecting your connection. Most people know it means “secure,” but the details are often fuzzy, and some of the common assumptions are wrong. This guide explains how HTTPS and TLS protect what you send and receive, what the padlock actually proves, the role of certificates and the authorities that issue them, and the important line between what TLS protects and what it leaves exposed.
HTTPS and TLS: The Relationship
HTTPS stands for Hypertext Transfer Protocol Secure. It is ordinary web traffic (HTTP) wrapped in a layer of protection. That protective layer is TLS, which stands for Transport Layer Security. You will sometimes still see the older name SSL (Secure Sockets Layer), but SSL is obsolete and has been replaced by TLS; the names are often used interchangeably in casual speech even though TLS is what actually runs today.
The relationship is simple to state. HTTP carries the web page. TLS is the secure channel that HTTP travels through. Without TLS, your requests and the site’s responses move across the internet as readable text that anyone in between could capture or alter. With TLS, that same traffic becomes an encrypted stream that intermediaries cannot read or tamper with undetected.
What TLS Actually Provides
TLS delivers three distinct protections at once, and it is worth keeping them separate because they answer different questions.
Encryption keeps the contents of your connection private. Data is scrambled so that anyone observing the network, such as someone on the same public Wi-Fi, your internet provider, or an attacker positioned in between, sees only unreadable ciphertext rather than your actual messages.
Integrity ensures the data is not altered in transit. TLS attaches a cryptographic check to the data so that if even a single bit is changed along the way, the tampering is detected and the connection is rejected. You can trust that what you received is exactly what the server sent.
Authentication confirms you are connected to the genuine server and not an impostor. Before any data flows, TLS verifies the server’s identity using a digital certificate. This is what stops an attacker from silently impersonating a website you are trying to reach.
Encryption without authentication would let you have a private conversation with the wrong party. Authentication without encryption would let you confirm the server but expose everything you said. TLS provides all three together, which is what makes it trustworthy.
How a TLS Connection Is Set Up
When your browser connects to an HTTPS site, the two sides perform a short negotiation called the TLS handshake before any web content is exchanged. The full process is detailed, but the logic follows a few clear steps.
1. Hello and Capabilities
Your browser announces which TLS versions and cryptographic methods it supports. The server replies, choosing a set both sides can use. This ensures the two ends agree on a common, secure configuration rather than falling back to something weak.
2. The Server Proves Its Identity
The server sends its digital certificate, which contains its public key and is signed by a trusted authority. Your browser checks that certificate (more on how below). This is the authentication step, and it is the part that stops impersonation.
3. Agreeing on a Shared Secret
The two sides then use public-key cryptography to establish a shared secret key that only they know, without ever sending that key across the network in a form an eavesdropper could use. Modern handshakes do this in a way that protects past sessions even if a key is later compromised, a property known as forward secrecy.
4. Switching to Fast Encryption
Once the shared secret is set, both sides switch to symmetric encryption, which is fast, to protect the actual web traffic for the rest of the session. Public-key cryptography handles the delicate job of agreeing on the key, then hands off to efficient symmetric encryption for the bulk data. This combination gives both strong security and good performance.
After the handshake, your browsing proceeds normally, but every request and response now travels inside that encrypted, integrity-checked channel.
What the Padlock Means (and Does Not)
The padlock icon is widely misunderstood, so it is worth being precise.
The padlock means your connection to the site is encrypted and the site presented a valid certificate for its domain name. In other words, your data is private in transit, and you really are talking to the server that controls that domain. That is genuinely valuable.
What the padlock does not mean is that the site is honest, safe, or run by a reputable organization. Obtaining a certificate has become easy and free, which is good for security overall because it pushed the whole web toward encryption. But it also means a scam site can display a padlock just as easily as a legitimate one. The padlock certifies the channel, not the character of whoever is on the other end. A phishing page hosted on an attacker’s own domain can be served over perfectly valid HTTPS.
The practical takeaway: treat the padlock as confirming “this connection is private and goes to this exact domain,” then check that the domain itself is the one you actually intended to visit. Our guide to phishing attacks covers how scammers exploit the gap between a valid padlock and an untrustworthy site.
Certificates and Certificate Authorities
The authentication that underpins TLS rests on digital certificates and the system that issues them.
A digital certificate is an electronic document that binds a public key to a domain name. When your browser connects, the certificate is how the server proves the public key it is using really belongs to that domain. But a certificate is only as trustworthy as whoever vouches for it, which is where certificate authorities come in.
A certificate authority (CA) is an organization that verifies the owner of a domain and then issues a signed certificate confirming that ownership. Your browser and operating system ship with a built-in list of CAs they trust. When a site presents a certificate, your browser checks that it was signed by one of these trusted authorities, that it has not expired, and that it matches the domain you are visiting. If any of those checks fail, you see a warning instead of the padlock. This forms a chain of trust: you trust your browser, your browser trusts a set of CAs, and those CAs vouch for individual sites.
The signature that makes this work depends on cryptographic hash functions. A certificate is signed by hashing its contents and encrypting that hash with the authority’s private key, so any change to the certificate would break the signature. The strength of the hash function therefore matters directly. This is not a theoretical concern: weaknesses in older hash functions have forced the industry to retire them from certificates, which is part of the story behind our own SHAttered research. To understand the hashing and signing that certificates rely on, see our cryptography section.
What TLS Does Not Protect
TLS is strong, but it has clear boundaries, and assuming it does more than it does can lull you into a false sense of safety.
TLS protects data in transit, between your device and the server, not data at rest on either end. Once your data arrives at the server, TLS no longer applies; how the company stores and secures it is a separate matter, and a breach of that stored data is unaffected by the encryption that carried it there. Equally, if your own device is infected with malware, TLS cannot help, because the threat is reading your data before it is ever encrypted or after it is decrypted.
TLS also does not vouch for the trustworthiness of the site, as the padlock discussion above makes clear. And while it hides the contents of your traffic, it does not fully hide the fact of the connection: an observer can still typically see which domain you connected to and how much data you exchanged, even if they cannot read the data itself. TLS secures the conversation; it does not make you anonymous.
Knowing these limits is part of using TLS well. It is one essential layer of online security, working alongside good passwords, breach awareness, and phishing vigilance, not a single shield that covers everything.
Frequently Asked Questions
Does the padlock mean a website is safe to use?
No. The padlock means your connection is encrypted and the site holds a valid certificate for its domain. It does not mean the site is honest or reputable. Scam sites can show a padlock too, so always confirm the domain is the one you actually meant to visit.
What is the difference between SSL and TLS?
They are the same idea at different stages of evolution. SSL was the original protocol; TLS is its successor and what every secure site uses now. The term “SSL” survives out of habit, but in practice the active protocol is TLS.
Is it safe to enter my password on any site with HTTPS?
HTTPS protects your password while it travels to the site, which is necessary, but it does not guarantee the site is legitimate. Make sure the domain is correct and the site is one you trust before entering credentials. A valid certificate on a fake domain still belongs to the attacker.
Why do certificates rely on hash functions?
Certificates are signed by hashing their contents and encrypting that hash with the certificate authority’s private key. The signature proves the certificate has not been altered. If the hash function is weak, that proof can be undermined, which is why the industry retires older hash functions from certificate use. Our cryptography section explains the underlying mechanism.
