HTTPS and TLS, what the padlock actually proves

Field note. Your game traffic isn't TLS-encrypted, but your panel definitely should be. Knowing what the padlock actually proves helps you spot the difference between 'real panel' and 'phishing panel.'

The padlock icon in your browser is famous. It's also widely misunderstood. People think it means "this site is safe" or "this site is legitimate." Both are wrong.

What the padlock actually means: the connection between you and the server is encrypted, and the server has presented a certificate that some certificate authority signed. That's it. Anything more is folklore.

This article explains what HTTPS and TLS actually do, what they don't do, and why they matter.

HTTP vs HTTPS

HTTP (Hypertext Transfer Protocol) is the protocol for moving web pages. By default, HTTP runs over TCP port 80. Plain text. Anyone watching the wire can read everything: URLs, page contents, form submissions, passwords.

HTTPS is HTTP wrapped in TLS (Transport Layer Security). Runs over TCP port 443. The TLS layer encrypts everything between client and server, so eavesdroppers see only encrypted gibberish.

The S in HTTPS literally stands for "Secure," meaning "wrapped in TLS." The protocol underneath is identical HTTP; only the transport is different.

What TLS provides

Three guarantees, when working correctly:

1. Confidentiality. Nothing between you and the server can read the contents of your traffic. They can see that you're connecting to a server at some IP, but not what you're sending or receiving.

2. Integrity. Nothing between you and the server can modify the traffic without detection. If a router or intermediate party tries to tamper with bytes, TLS will detect it.

3. Authentication. The server proves it is who it claims to be by presenting a cryptographic certificate that some trusted Certificate Authority (CA) has signed.

What TLS doesn't provide:

• Proof that the server is "trustworthy." A scam site can absolutely have a valid TLS certificate.
• Privacy from the server itself. The server you connect to sees your data in plaintext.
• Privacy of metadata. Observers still see which IP you connected to and roughly how much data you exchanged.

The handshake

When you load an HTTPS site, before the first byte of HTTP can flow, a TLS handshake happens. Simplified:

1. Client Hello. "Hi, I support these encryption algorithms; here's a random nonce; please tell me your certificate."
2. Server Hello. "Hi, let's use this algorithm; here's my certificate; here's my nonce."
3. Key Exchange. Client and server derive a shared secret key using public-key cryptography. The key is unique to this session.
4. Encrypted communication starts. All subsequent bytes are encrypted with the session key.

Modern TLS 1.3 (RFC 8446, 2018) compresses this further: 1 round-trip handshake for a new connection, 0 round-trips for a resumed one. This is meaningful for performance on high-latency connections.

The certificate

The server's certificate is a structured document containing:

• The server's hostname(s) (example.com, *.example.com).
• The server's public key.
• The certificate authority's identity.
• The certificate authority's signature, proving they signed it.
• Validity dates (typically 3 months to 13 months).
• Various extensions (allowed uses, etc.).

When the client receives the certificate:

1. Verify the signature. The CA's signature is checked using the CA's public key (which is bundled in the OS/browser).
2. Verify the hostname. The certificate must include the hostname the client connected to.
3. Verify the dates. Certificate must be currently valid.
4. Verify revocation status. Has this certificate been revoked since issuance? (Done via CRL or OCSP, though browsers vary in how strictly they check.)

If all checks pass, the certificate is "valid" and the handshake proceeds.

The certificate authority system

CAs are the trust anchor for HTTPS. Browsers and operating systems ship with a list of roughly 100 "trusted" CAs. Their public keys are pre-installed. Any certificate signed by one of these CAs is "trusted" by default.

Major CAs include:

• Let's Encrypt (free, automated)
• DigiCert
• GlobalSign
• Sectigo
• Google Trust Services
• Amazon Trust Services

When you want a certificate for your domain, you contact a CA (directly or through a hosting provider) and prove control of the domain. Modern automated systems (ACME, the protocol Let's Encrypt uses) let this happen without human involvement.

The CA system is somewhat fragile: if any of the ~100 trusted CAs is compromised, attackers could issue valid-looking certificates for any domain. This has happened (DigiNotar in 2011, others), and the response is usually rapid removal of the CA from trust stores.

Browsers have added mitigations:

• Certificate Transparency: all certificates must be logged publicly, so anyone can detect rogue certs.
• CAA records (covered in DNS article): domains can declare which CAs are allowed to issue for them.
• HPKP (HTTP Public Key Pinning): originally a way to pin specific keys; mostly abandoned because of its own footguns.

What "trust" actually means

When you see the padlock, what's being trusted is:

1. The browser trusts the CA that signed the certificate.
2. The CA verified that whoever requested the certificate has control of the hostname.

This is a weak claim. It says nothing about:

• Whether the site is legitimate, ethical, or non-malicious.
• Whether the site's owner is who they claim to be in real life.
• Whether the site sells legitimate products.
• Whether the site will treat your data well.

A phishing site for g00gle.com can have a perfectly valid certificate. The CA verified that the requester controls g00gle.com, which they do. The padlock is fine. The site is still a scam.

For years, browsers showed "EV" (Extended Validation) certificates differently (with the company name in green). The idea was to convey "we verified this company more thoroughly." Research showed users didn't notice or understand. Most browsers have dropped the EV UI by 2026.

Bottom line: the padlock is a transport-security indicator, not an authenticity-of-business indicator.

The HTTPS-everywhere movement

For most of the web's history, HTTPS was optional. Sites with login forms used it; static sites didn't bother. The expense and complexity of TLS certificates discouraged universal adoption.

Several changes turned this around:

Let's Encrypt (2015) provided free, automated certificates. The financial barrier disappeared.

Browsers started marking HTTP as "Not Secure" (Chrome's campaign, 2016 onward). Visitors saw warnings on HTTP sites.

Google's search ranking started favoring HTTPS (2014). SEO incentive.

HTTP/2 essentially requires HTTPS in practice. Browsers don't implement HTTP/2 over plain HTTP.

By 2026, the vast majority of web traffic is HTTPS. Plain HTTP is increasingly rare.

TLS in non-web contexts

TLS isn't just for HTTPS. Many protocols use it:

• SMTP with STARTTLS (email transit).
• IMAPS, POP3S (email retrieval).
• LDAPS (directory services).
• MQTT-S (IoT messaging).
• DoT, DoH (encrypted DNS).
• WebSockets over TLS (real-time web).
• Some game protocols for login flows.

The TLS layer is generic. Any TCP-based protocol can add TLS as a wrapper for the same three guarantees.

What's not in TLS

Some specific gaps:

TLS doesn't encrypt UDP. UDP-based protocols use DTLS (Datagram TLS) for the same purpose. Used by WebRTC, some VPNs, some games.

TLS doesn't protect against compromised endpoints. If the server's been hacked, encryption between you and it doesn't matter.

TLS doesn't protect metadata. Observers can still see which IPs are talking, when, and how much.

TLS handshake includes the hostname (SNI). Even though traffic is encrypted, the hostname is plaintext during the handshake. ECH (Encrypted Client Hello) addresses this; rolling out gradually in 2024-2026.

Common HTTPS issues

For server operators, things that can go wrong:

Certificate expired. The most common avoidable error. Always automate renewal.

Certificate doesn't match the hostname. You requested for example.com but are using it on service.example.com. Get the right one.

Mixed content. An HTTPS page loads an HTTP resource. Browsers block or warn. Fix by using HTTPS for everything.

Old TLS version. TLS 1.0 and 1.1 are deprecated. Browsers reject. Make sure your server supports TLS 1.2+ (1.3 if possible).

Weak cipher suite. Old, weak crypto algorithms can be selected if you allow them. Configure your server to require modern ciphers.

Self-signed certificate. A certificate not signed by a trusted CA. Browsers warn. Acceptable internally, not for public sites.

Tools like Qualys SSL Labs scan your server and grade its TLS configuration. A grade of A or A+ is achievable for free with modern config.

Performance

TLS adds overhead but less than people fear:

• Initial handshake: a few hundred microseconds to single-digit milliseconds CPU.
• Per-byte encryption: minimal on modern hardware (AES-NI accelerates it).
• TLS 1.3 with session resumption: nearly free for repeat connections.

For an average website, HTTPS is essentially zero cost over HTTP. For very high traffic sites, modest cost manageable with caching and modern crypto.

What HTTPS means for games

Most game traffic doesn't use HTTPS. Real-time game protocols use UDP and have their own crypto choices (some use DTLS, some use custom encryption, some don't encrypt much).

What does use HTTPS in gaming:

• Login flows.
• Account management.
• In-game store transactions.
• Patches and updates.
• Backend API calls.

So your Minecraft login is HTTPS-secured. Your in-game position updates are not necessarily. The login matters for security; the position updates matter for performance, and the protocols differ.

Conclusion

HTTPS via TLS is the workhorse of modern internet security. It provides:

• Confidentiality (eavesdroppers see nothing).
• Integrity (tampering detected).
• Authentication of the server (with limitations).

It does not provide:

• Authentication of the business behind the site.
• Privacy from the server itself.
• Protection of metadata.

The padlock is a transport-security indicator. It's necessary but not sufficient for "this site is safe." For ordinary users, the key behaviors:

• Use HTTPS sites whenever possible (almost always these days).
• Be skeptical of "this site is safe because there's a padlock."
• Use a password manager (it won't autofill on the wrong domain).
• Check addresses carefully on sites where money matters.

Coming up

We've covered everything from the wire to the encrypted application layer. The last article in Series A: CDNs, the global infrastructure that makes the internet feel fast despite physical distance.