Security
How HTTPS actually works
Type https:// and, before a single byte of the page arrives, your browser and the server run a fast back-and-forth called the TLS handshake. In a fraction of a second it answers two questions: are you really who you claim to be? and can we agree on a secret only we two know? Get those right and everything after is private.
The handshake, step by step
The two jobs it does
Proving identity. The server sends a certificate — a document signed by a trusted Certificate Authority (CA) that vouches "this really is codedrives.com." Your browser ships with a list of CAs it trusts, so it can check the signature. If the cert is missing, expired, or for the wrong domain, you get the scary warning page. (This is exactly what tools like Let's Encrypt issue for you.)
Agreeing on a secret. Using the server's public key, the two sides safely agree on a fresh session key that only they know — even though the whole negotiation happened in the open. From that point, everything is encrypted with that key.
The padlock means two things happened: your browser checked the server's ID (the certificate), and the two agreed a private key no eavesdropper can derive. After that, the conversation is sealed.
What it protects — and what it doesn't
- Privacy: someone on the same Wi-Fi (or your ISP) sees which site you visited, but not the content — passwords, messages, and pages are scrambled.
- Integrity: the data can't be secretly altered in transit without breaking the seal.
- Authenticity: you're talking to the real server, not an impostor in the middle.
What HTTPS does not promise: that the site itself is trustworthy. A phishing page can have a perfectly valid padlock. HTTPS secures the pipe, not the intentions of whoever's on the other end — so the lock means "this connection is private," not "this site is safe."