Summary of "Web Security - Lecture 11 - Transport Layer Security"
Summary of “Web Security - Lecture 11 - Transport Layer Security”
Part 1: Recap on SQL Injection (Brief)
- Time-based blind SQL injection can leak sensitive data (e.g., passwords) by measuring differences in query execution time.
- The core problem arises when the application server constructs database queries that users can modify, allowing bypass of access controls.
- Typical architectures rely on server-side access control rather than database-level access control.
- Solutions to SQL Injection:
- Parameterized SQL queries: Use placeholders (e.g.,
?) and pass user input separately so the database driver properly escapes inputs. - Object-Relational Mappers (ORMs): Abstract database rows as objects; ORM methods safely handle input escaping.
- Parameterized SQL queries: Use placeholders (e.g.,
- Even with ORMs or NoSQL databases, injection risks remain if user input is directly used to construct queries or query objects.
- Key takeaway: Never concatenate untrusted input directly into queries; always use parameterization or ORM methods.
Part 2: Introduction to TLS (Transport Layer Security)
- Problem with HTTP: It is unencrypted; all data (requests, responses, cookies, passwords) is visible to any network observer (passive attacker).
- Active attackers can modify data in transit, injecting malicious scripts or redirecting users.
- Network attackers can be routers, ISPs, DNS servers, or border gateways capable of eavesdropping, modifying, or blocking traffic.
- Security goals in the presence of network attackers:
- Privacy: Prevent eavesdropping.
- Integrity: Prevent tampering.
- Authentication: Ensure communication is with the intended server.
- All three properties are essential; without authentication, privacy and integrity are meaningless.
Part 3: Anonymous Diffie-Hellman Key Exchange (DH)
- DH allows two parties (client and server) to agree on a shared secret key over an insecure channel.
- Uses a cyclic group and exponentiation with a public base
G. - Client picks secret
a, sendsG^a; server picks secretb, sendsG^b. - Both compute shared key
G^(ab)independently. - Weakness: This is anonymous — no authentication of the server, so vulnerable to man-in-the-middle (MITM) attacks.
- MITM attack example: Attacker intercepts and replaces keys, establishing separate keys with client and server, relaying messages undetected.
Part 4: Adding Authentication with Public Key Cryptography
- Use digital signatures to authenticate the server during the DH key exchange.
- Server has a public/private key pair; the public key is known to the client.
- Server signs the transcript of the key exchange (e.g.,
G^a) with its private key. - Client verifies the signature using the server’s known public key.
- This prevents MITM attacks because the attacker cannot forge the signature.
- Server authentication is one-way; the client remains anonymous.
- Client can now safely send credentials over the encrypted channel.
Part 5: How Does the Client Get the Server’s Public Key?
- The client cannot trust the server to send its own public key during the handshake (would allow MITM).
- Solution: Certificate Authorities (CAs)
- Trusted third parties that issue digital certificates binding domain names to public keys.
- Browsers come pre-loaded with a list of trusted CAs.
- Server presents its certificate signed by a trusted CA.
- Client verifies the certificate chain and domain name before trusting the public key.
- Certificates include:
- Common Name (CN): Domain the certificate is valid for.
- Subject Alternative Names (SANs): Additional domains covered.
- Signature from the CA.
- Wildcard certificates (e.g.,
*.example.com) cover subdomains.
Part 6: Certificate Authorities and Trust
- Browsers maintain a list of trusted root CAs.
- Some CAs are government entities or companies worldwide.
- Compromise or misbehavior by a CA can undermine the security of all sites trusted by that CA.
- Examples of CA compromises:
- Fake certificates issued for Gmail in Iran.
- CA resellers hacked and issued fraudulent certificates.
- Browsers can remove trust from CAs to mitigate damage.
- Employers sometimes add their own CA to inspect employee traffic, effectively performing MITM within their networks.
Part 7: TLS Protocol Overview and TLS 1.3
- TLS 1.3 is the latest version, fixing many flaws from previous versions (SSL, TLS 1.0, 1.1, and 1.2).
- Two phases:
- Establish shared secret (key exchange with authentication).
- Encrypt all subsequent communication with the shared key.
- TLS handshake messages include:
- ClientHello and ServerHello (including key shares).
- Certificate exchange.
- Finished messages.
- Use of nonces prevents replay attacks and enables features like zero round-trip time (0-RTT).
- Certificates are encrypted during handshake to hide server identity from passive observers.
- TLS 1.3 supports forward secrecy:
- Even if the server’s long-term private key is compromised, past communications remain secure because ephemeral keys are discarded after use.
Part 8: Browser Behavior and HTTPS Adoption
- Browsers show a lock icon only if all page resources (scripts, images, etc.) are loaded over HTTPS.
- Mixed content (HTTP resources on HTTPS pages) breaks the lock.
- HTTPS adoption has increased dramatically, especially among top sites, driven by:
- Browser warnings labeling HTTP as “Not Secure”.
- Free certificates from Let’s Encrypt.
- Some legacy devices and ad networks slow full adoption.
- Google’s transparency reports show high HTTPS usage but not 100%.
Part 9: TLS Strip Attack and HTTP Strict Transport Security (HSTS)
- TLS Strip Attack:
- Attacker intercepts initial HTTP request before redirect to HTTPS.
- Attacker prevents redirect, proxies HTTPS connection to server but serves HTTP to client.
- Attacker modifies HTML links to keep client on HTTP, enabling ongoing MITM.
- HSTS (HTTP Strict Transport Security):
- Server sends
Strict-Transport-Securityheader instructing browsers to always use HTTPS for that domain. - Protects users from TLS strip attacks after the first successful HTTPS connection.
- Limitation: First connection is vulnerable (Trust on First Use model).
- Server sends
- HSTS Preload List:
- Browsers maintain a hardcoded list of domains that must always use HTTPS.
- Domains opt-in by sending headers with
preloadand submitting to a central list. - Preload list solves the first-connection vulnerability.
- Removal from preload list is difficult and slow.
Part 10: Additional Notes and Future Topics
- Client certificates for mutual TLS authentication exist but are rarely used.
- Public Key Pinning and Certificate Transparency are advanced topics to enhance TLS security.
- TLS is a complex and evolving protocol critical to web security.
Main Concepts and Lessons
- SQL Injection prevention: Use parameterized queries or ORMs; never concatenate untrusted input.
- TLS provides privacy, integrity, and authentication in the presence of network attackers.
- Anonymous DH key exchange is vulnerable to MITM; authentication via signatures fixes this.
- Certificate Authorities enable trust in server public keys; browsers trust a set of CAs.
- TLS 1.3 improves security with forward secrecy and encrypted handshakes.
- HTTPS adoption is widespread but not universal; browser UI encourages adoption.
- TLS strip attacks exploit initial HTTP connections; HSTS and preload lists mitigate this.
- Security involves trade-offs, e.g., privacy vs. security in clearing HSTS state.
Methodologies / Instructions Highlighted
- To prevent SQL injection:
- Use parameterized queries with placeholders.
- Use ORM methods that safely escape user input.
- To establish a secure TLS connection:
- Perform Diffie-Hellman key exchange.
- Authenticate the server via digital signatures.
- Verify server certificate against trusted CA list.
- Use TLS 1.3 protocol for forward secrecy and encrypted handshake.
- To prevent TLS strip attacks:
- Implement HSTS header with long max-age.
- Opt into HSTS preload list.
- To verify certificates:
- Check CA signature validity.
- Confirm domain matches certificate CN or SAN.
- Check certificate expiration.
- For TLS key exchange:
- Include nonces to prevent replay attacks.
- Sign handshake transcript to prevent MITM.
Speakers / Sources Featured
- Primary Speaker: The lecturer of the course (likely a Stanford professor or instructor).
- Referenced Lectures: Dan Bernay’s lecture from CS 255 (Intro to Cryptography).
- Guest Lecturers Mentioned: Emily and Chris from Google Chrome (discussing public key pinning and certificate transparency).
- Referenced Organizations: Google (Google Trust Services, Google HTTP Transparency Report), Let’s Encrypt, various Certificate Authorities (including Symantec, Komodo), Mozilla (for CA trust decisions).
This summary captures the main ideas, technical concepts, and practical security lessons from the lecture on TLS and related web security topics.
Category
Educational
Share this summary
Is the summary off?
If you think the summary is inaccurate, you can reprocess it with the latest model.
Preparing reprocess...