How HTTPS Keeps Your Data Secure: What It Protects, What It Does Not and How to Check

Key takeaways

• HTTPS protects three things in transit: confidentiality, integrity and server authenticity.
• Public-key cryptography agrees on a key and proves identity; symmetric encryption then protects the data.
• The padlock proves a private connection to a domain, not that the site is safe.
• Misconfigurations such as mixed content, expired certificates and missing HSTS weaken protection.
• Check any site by reading the domain, then the certificate details in the browser.

What problem does HTTPS solve?

Web traffic crosses networks you do not control: your Wi-Fi router, your ISP, the cafe hotspot, many routers on the way. On plain HTTP, anyone on that path can read the content and change it. HTTPS wraps HTTP in TLS to stop that. For the full handshake, see how HTTPS works, step by step. This article looks at what HTTPS actually protects, with an example, and where its protection ends.

What does HTTPS protect against?

What does a login look like with and without HTTPS?

Imagine you sign in to a site with the username asha and a password. This is an illustration, not a real capture.

On HTTP, your browser sends a request such as POST /login with the body user=asha&pass=... as readable text. Someone on the same public Wi-Fi who can capture packets sees the password and the session cookie that comes back. They can reuse that cookie to act as you.

On HTTPS, the browser first completes a TLS handshake, then sends the same request inside the encrypted connection. The observer sees only that your device is talking to the server's IP address and the server name used in the handshake, plus encrypted bytes of a certain size. The password and cookie are unreadable, and any change to the bytes is detected.

How do keys and certificates make this work?

• Certificate: proves that the server controls the domain, signed by a certificate authority your browser trusts.
• Key exchange: client and server compute the same secret using public-key methods, without sending it. Modern TLS uses ephemeral keys, so recorded traffic cannot be decrypted later if a server key leaks.
• Symmetric encryption: after the handshake, a fast cipher such as AES-GCM or ChaCha20-Poly1305 encrypts and authenticates each record.

A simple analogy: the certificate is the verified identity card of the shop, the key exchange is two people agreeing a secret code without shouting it across the room, and the symmetric cipher is the code itself used for the conversation.

What can still go wrong?

• Mixed content: an HTTPS page that loads a script or image over HTTP. Browsers block most active mixed content, but it should be fixed.
• SSL stripping and downgrade: an attacker keeps you on HTTP when you type a bare domain. The Strict-Transport-Security (HSTS) header tells browsers to use HTTPS only.
• Expired or misissued certificates: cause errors and can be abused if users click through warnings.
• Weak configuration: old protocol versions or ciphers. Configure TLS 1.2 and 1.3 and disable obsolete ones.
• Malicious but valid sites: a phishing site can have a valid certificate. HTTPS shows that the connection is private, not that the site is legitimate.
• Endpoints: malware on your device or a compromised server can read data before encryption or after decryption.
• Metadata: the domain name (through DNS and the server name indication) and traffic size remain visible.

Is HTTPS unbreakable?

The cryptography in current TLS is considered strong when properly configured. Most real incidents come from the edges: stolen private keys, compromised certificate authorities, misconfiguration, old software, user error and attacks on endpoints. So HTTPS is necessary, not sufficient.

How do you check whether a site is using HTTPS properly?

1. Read the domain in the address bar first. This matters more than the padlock.
2. Click the padlock icon and open the certificate details to see the domain names covered, the issuer and the expiry date.
3. Open browser developer tools and look at the Security or Network tab to see the protocol and cipher, and any mixed content warnings.
4. For your own site, use a tool such as openssl s_client -connect yoursite.com:443 -servername yoursite.com, and run an online TLS configuration test. Confirm that HTTP redirects to HTTPS and that HSTS is present.

Common mistakes

• Trusting a site because it has a padlock.
• Clicking through certificate warnings.
• Forgetting to renew certificates.
• Leaving admin or API endpoints on HTTP.

Next steps

Read how an SSL/TLS certificate works and the beginner guide to SSL/TLS. For deeper study, see our cyber security course. TLS 1.3 is specified in RFC 8446.

Related reading

• How to Secure Your Website | A Step-by-Step Guide to Moving from HTTP to HTTPS
• What Is Cryptography? Algorithms, Types, Tools & Applications Explained