Cybersecurity › Module 4 › Lesson 4
HTTPS, SSL, and TLS
The padlock protects the path — not the destination's honesty
Opening
That tiny padlock built modern commerce
Hashing gave you integrity fingerprints. HTTPS gives you encrypted transport. Without TLS, café Wi-Fi could read passwords in flight. With TLS, eavesdroppers mostly see ciphertext. Still: a padlock does not prove the site is Amazon — only that your tunnel to whoever owns that certificate is encrypted and authenticated to a domain name. Padlock ≠ honesty.
1. HTTP vs HTTPS
HTTP sends application data without transport encryption — anyone on the path can read and often alter what you type. HTTPS is HTTP over TLS (Transport Layer Security; historically people said SSL). The "S" means Secure transport: confidentiality and integrity for data in transit, plus server authentication via certificates. You still type the correct domain; TLS does not invent trust in a scam URL.
2. SSL vs TLS (names you will hear)
SSL (Secure Sockets Layer) is the obsolete ancestor. TLS is the modern protocol family browsers and servers actually negotiate. People still say "SSL certificate" out of habit; under the hood, healthy stacks run TLS. If a site only offers ancient SSL, treat that as a red flag — retire old crypto.
3. Handshake in learner-visible steps
Every HTTPS visit begins with a handshake — the hybrid story from Lesson 2, now named for what you can picture in the browser. Exact message names differ slightly by TLS version, but the learning path is:
What your browser and the server do before the page loads:
1. ClientHello
Browser announces supported TLS versions and cipher suites ("here is modern crypto I speak").
2. ServerHello + certificate
Server picks parameters and presents an X.509 certificate: public key + domain binding + signatures from a Certificate Authority (CA) chain.
3. Browser certificate checks
Domain match, validity dates, and trust chain (details in the next section). Fail → blocking warning.
4. Key agreement
Both sides establish ephemeral session secrets without mailing an AES key in the clear.
5. Encrypted application data
HTTP requests/responses ride inside the symmetric session. That is the padlock tunnel.
4. What the browser checks on a certificate
A certificate is a digitally signed statement: "this public key belongs to this name, for this time window, vouched by this CA." Your browser does not blindly trust any PDF of a lock icon. It runs checks:
Domain (name) match
The hostname you typed (e.g. bank.example) must appear in the certificate's subject / SAN fields. A valid cert for evil-bank.example does not authorize bank.example.
Validity window
NotBefore / NotAfter dates must include "now." Expired or not-yet-valid certs trigger warnings.
Trust chain
The cert must chain up to a root CA already trusted by your OS/browser (intermediate CAs in between). Self-signed or unknown roots fail unless you explicitly trust them (dangerous for banking).
What you still do not get
Proof the business is ethical, malware-free, or not a lookalike phishing domain with its own legit cert.
5. HSTS in one minute
HTTP Strict Transport Security (HSTS) is a server policy that tells browsers: "for this domain, only use HTTPS for a declared period — do not fall back to cleartext HTTP." After a successful HTTPS visit (or via a preload list), the browser refuses insecure HTTP upgrades that attackers love on hostile Wi-Fi. HSTS does not make a phishing domain honest; it hardens transport for the real domain you already trust.
6. Wrong vs right: trusting the padlock blindly
Worked failure mode — https://amaz0n-secure-login.example phishing:
Wrong
Victim sees a padlock, relaxes, and types banking credentials. TLS encrypted the path to the attacker's server. Confidentiality to the wrong destination is still a disaster. Clicking through certificate errors makes it worse.
Right
Check the domain spelling carefully, prefer bookmarks/official apps, and never click through red certificate warnings. Padlock = encrypted, authenticated path to that domain. You still verify you meant that domain — and remember padlock ≠ honesty.
7. Practical: read the lock, optional openssl view
Command guide
Browser TLS hygiene + optional s_client (allowed hosts only)
On sites YOU intend to use:
Command — copy this
1. Confirm URL starts with https:// 2. Click the padlock → view certificate / site info 3. Domain in cert should match the site you meant 4. Note validity dates; chain should lead to a trusted CA 5. If browser shows "Your connection is not private" / NET::ERR_CERT_* → STOP. Do not click through. Often signals broken config OR active interception.
HSTS (concept): after HTTPS, browser may refuse plain HTTP for that domain — good for the real site, not a scam filter.
Optional educational inspect (YOUR machine; hosts you may test):
Optional command
openssl s_client -connect example.com:443 -servername example.com </dev/null
Windows PowerShell tip: use OpenSSL in PATH, then Ctrl+C after output. Only against hosts you are allowed to test (e.g. public example.com, or your own servers). Do not probe random third-party systems.
Remember: HTTPS ≠ "safe website." HTTPS ≠ antivirus. Padlock ≠ honesty.
Command guide
Terminal practice (Linux / Kali / macOS — YOUR machine only)
Observe HTTPS/TLS from YOUR terminal (public demo host only) Linux / Kali / macOS
Command — copy this
mkdir -p "$HOME/cyberlium-lab" cd "$HOME/cyberlium-lab" curl -I https://example.com
Optional cert peek (Ctrl+C after banners if it hangs waiting):
Optional command
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -dates
Windows PowerShell
Command — copy this
curl.exe -I https://example.com
Or: Invoke-WebRequest -Method Head -Uri https://example.com
Browser still matters: type https:// yourself, click the padlock, confirm the name. NEVER: intercept others' TLS, spoof certs, or attack real banks
Mission: padlock vs phishing awareness
Visit one legitimate site you already use. Open the padlock/certificate view and note: (1) the domain shown, (2) whether dates look valid, (3) that a trust chain exists. Then write one sentence: why a random https site could still be a scam. Optional: run openssl s_client against a host you are allowed to test (e.g. example.com) and skim the cert subject.
Stuck? Ask Cyberlium AI Mentor
Confused why phishing sites can have HTTPS, or what HSTS changes? Ask Cyberlium AI Mentor for a hint — not help bypassing certificate errors. Try: "Hint only: what does the padlock guarantee vs not guarantee?" Or: "Hint only: name three checks a browser runs on a TLS certificate."
You now read HTTPS as encrypted transport with certificate-based server auth — domain, validity, trust chain — plus a brief HSTS boost against HTTP downgrade. Powerful, not omniscient: padlock ≠ honesty. Next — Lab — Encrypt & Decrypt — see plaintext become ciphertext, then practice safe local openssl commands.
Knowledge Check
APPLY: A site shows a valid padlock. Does that guarantee it is not a phishing scam?
Multiple choice
Knowledge Check
APPLY: Which trio best matches what a browser checks on a server certificate?
Multiple choice
Knowledge Check
APPLY: Your browser shows a full-screen certificate error on your bank URL. Best action?
Multiple choice