HTTPS (Hyper Text Protocol Secure) is HTTP over SSL/TLS. All communication between your browser and a website is encrypted. HTTP sends cleartext; a network attacker can intercept passwords, cookies, and other sensitive data.
User sends password; server receives it. Attacker on the link
gets "helloworld" in plain view.
Same flow, but traffic is encrypted. Attacker sees only
"Xu587Fyus)"-like ciphertext, not the real
password.
Crypto can slow web servers (if not done right). Some ad networks didn't support HTTPS. Reduced revenue for publishers.
Google (Aug 2014) boosts ranking of sites supporting HTTPS. Today most major sites use HTTPS by default.
Controls network infrastructure (routers, DNS). Can eavesdrop, inject, block, and modify packets. Examples: wireless at a café, hotel Internet (untrusted ISP).
TLS (Transport Layer Security) provides public-key cryptography. The
server has a key pair (SK, PK). The browser encrypts
messages with the server's public key; only the server can decrypt
with its private key.
HTTP data encrypted with derived key KDF{k}.
Request URL, query parameters, headers, cookies, host addresses, port numbers, amount of transferred data, and session length - all encrypted.
How does the browser obtain the server's public key? A
Certificate Authority (CA)
issues a certificate binding identity (e.g.,
cc.gatech.edu) to a public key. The browser trusts CAs;
it verifies the cert and uses the public key.
Explicit name (e.g. cc.gatech.edu) or wildcard
(*.gatech.edu). * must be in leftmost
component; *.a.com matches x.a.com but
not y.x.a.com.
Browsers trust many CAs: ~60 top-level, ~1200 intermediate CAs. Any compromised CA can issue certs for any domain.
The lock is intended to show: (1) identity of the page origin, (2) that contents were not viewed or modified by a network attacker. In reality, many problems weaken this assurance.
Loading insecure (HTTP) content on a secure (HTTPS) page breaks the lock and can leak data.
Public caching cannot occur - proxies typically cannot cache HTTPS responses.
HTTPS introduces some latency (handshake, crypto). Modern TLS is optimized; impact is usually small.
You do not need to buy an SSL certificate - Let's Encrypt provides free certs. Browser caching works with HTTPS.
Three main problem areas: (1) upgrade from HTTP to HTTPS, (2) forged certs, (3) mixed content.
Attacker sits between user and server. When user requests
https://bank.com, attacker
prevents the upgrade - forwards request to bank
over HTTPS, receives response, then serves user over
HTTP. User sees no certificate error; traffic is
cleartext to the attacker.
User↔Attacker: HTTP. Attacker↔Server: HTTPS. Attacker sees everything.
2011: Comodo, DigiNotar hacked - certs issued for Gmail, Yahoo!. 2013: TurkTrust issued cert for gmail.com. 2014: Indian NIC (intermediate CA) issued certs for Google, Yahoo!. 2015: MCS (CNNIC) issued certs for Google. Attackers can MITM with rogue certs.
Attacker has cert for "bank.com" from a valid (compromised) CA. User connects to bank; attacker intercepts, presents rogue cert. User sees valid lock. Attacker decrypts with k1, re-encrypts with k2 to real bank. Both sides use HTTPS; attacker reads all traffic.
Page loaded over HTTPS but includes HTTP resources (scripts, images, iframes). Browser may block or downgrade; sensitive data can leak to HTTP endpoints.
Header tells browser to always connect over HTTPS. Subsequent visits must use HTTPS; HTTP and self-signed certs cause errors. TOFU: Trust on First Use - first visit must be over HTTPS for header to take effect. HSTS flag is deleted when user "clears private data" (security vs. privacy tradeoff).
Site declares which CAs can sign its cert. Browser rejects certs from other CAs on subsequent visits. Example header:
HPKP was deprecated due to operational risks (pinning to wrong key = site unreachable).
CAs must advertise a public log of all certs they issue. Browsers only accept certs published in a log. Companies (e.g. Google) scan logs for invalid issuance. Efficient implementation via Merkle hash trees.
Browser mechanism for stricter error processing. Site opts in via cookie; browser treats HTTPS errors as attacks, redirects non-HTTPS to HTTPS, terminates on TLS errors, blocks insecure embedded content.