HTTPV: Demonstrating the Absurdity of Max-Security with an Intentionally Insecure HTTPS Website

suckerpinch

Introduction to "Toxic Max-Security" and Personal Frustration [0:00]

• Love for Cryptography and HTTPS [0:00]
  • Tom expresses appreciation for cryptography and HTTPS for securing sensitive online activities like banking and managing YouTube channels.
• Frustration with Over-Security [0:18]
  • An animated sequence depicts Tom's intense frustration with modern web browsing experiences.
• The Antiquity of Tom's Website [0:41]
  • Tom's personal website, dating back to at least 1996, is highlighted as one of the oldest on the internet.
  • It features nostalgic content like "The Illustrated Guide to Breaking Your Computer."
  • He notes that being in the "top 5% of the web" is no longer impressive due to the proliferation of AI-generated content and scams.
• Desire for Open Access [1:28]
  • Tom desires a public website that is easily accessible without mandatory logins, cookie permissions, notification prompts, or "better in our app" redirects.
• Defining "Toxic Max-Security" [2:02]
  • "Toxic Max-Security" is defined as turning security settings to the maximum, which can scare users, create unnecessary work for developers, and potentially reduce overall security due to "alarm fatigue."
• Chrome's "Not Private" Warning on tom7.org [2:44]
  • Tom demonstrates a red alert in Chrome when trying to access his own public website (tom7.org), stating "Your connection is not private" and warning about potential theft of passwords or credit cards.
  • Users must click "Advanced" and then "Proceed to tom7.org (unsafe)" to bypass the warning.
  • Tom argues this warning is absurd for a public site with no sensitive information.
• Declaring "Beefs" with the Chrome Team [3:56]
  • Tom expresses his strong disagreement with the Chrome team for impeding access to his website due to "toxic max-security."
  • He questions the longevity of digital projects and human legacy in an increasingly tech-driven world.
• The "Pre-Paid Self-Own" Project: HTTPV [4:15]
  • The video's purpose is introduced as an "extended petty project" – a symbolic revenge against stringent web security.
  • His project is named "No one can force me to have a secure website!!!" or HTTPV (HTTP Vulnerable / Very), presented as a "pre-paid self-own."

Understanding HTTP and HTTPS Security [5:07]

• HTTP vs. HTTPS: The Basics [5:07]
  • HTTPS is presented as the more complicated, younger brother of HTTP, with the "S" standing for secure, enabled by TLS (Transport Layer Security).
• HTTP Communication Process [5:51]
  • A client (user's computer) sends a request to a server (website) for a webpage. The server sends back the content.
  • This communication is unencrypted and visible to anyone monitoring the traffic.
• The Man-in-the-Middle Problem and Basic Encryption [6:11]
  • A "hacker" can intercept HTTP messages, view requests, and alter responses.
  • Encryption using public/private key pairs is introduced as a solution to hide data.
  • However, a fundamental flaw exists: a hacker could trick the client into encrypting data with the hacker's key, allowing the hacker to read the message before re-encrypting it with the server's key and forwarding it.
• The Authority Problem: Certificate Authorities (CAs) [7:18]
  • To verify who owns which key, "Certificate Authorities" (CAs) endorse that a specific key belongs to a domain.
  • The process involves proving domain ownership to a CA to obtain a certificate.
• Critique of Certificate Authorities [8:28]
  • Browsers pre-install root certificates from various CAs (e.g., Microsoft, Digicert).
  • Concerns are raised about root certificates installed by less reputable entities (e.g., 3D mouse drivers, potentially state-authorized CAs with poor ratings or suspicious names like "Bypass Class 2 Root CA").
  • The CA system is described as a "racket" where CAs profit from selling certificates, forcing website owners to comply.
• Let's Encrypt: Automated and Free CA [10:25]
  • Let's Encrypt, a non-profit and mostly automated CA, provides free HTTPS certificates.
  • The process involves proving domain ownership by placing a specific token on the website for Let's Encrypt to verify.
  • Tom highlights the hypocrisy: if a hacker can control a website to place the token, they can still obtain a certificate, undermining the trust model.
• TLS Reverse Proxies (e.g., Cloudflare) [12:20]
  • CDNs like Cloudflare offer TLS reverse proxy services: they handle HTTPS encryption for users, while fetching content from the origin server via unencrypted HTTP.
  • This provides a green padlock to the user but allows the origin server operator (Tom) to avoid implementing HTTPS, transferring the security burden to the CDN.

HTTPV's Deliberate Insecurity Mechanisms [13:09]

• HTTPV Design Goals [13:24]
  • The primary goals for HTTPV are to work in real browsers, show a green padlock, and deliberately introduce specific vulnerabilities without risking buffer overflows or computer control.
  • He insists on implementing all cryptography himself, avoiding libraries like OpenSSL.
• Subverting RSA (Too Many Secrets) [19:04]
  • RSA is a public-key cryptosystem where the public key n is a product of two large primes p and q. Decryption requires knowing p and q.
  • Let's Encrypt requires a minimum of 2048-bit keys. Tom uses a 4096-bit key.
  • Instead of two large primes, Tom's RSA key is a product of 16 smaller, 256-bit primes. This is technically a 4096-bit key, which Let's Encrypt endorses.
  • This multi-factor key is surprisingly resistant to certificate revocation, as successful revocation requires finding all prime factors to generate a valid revocation signature.
• Poisoning the Initialization Vector (Poison I.V.) in AES-CBC [23:02]
  • AES (Advanced Encryption Standard) is a block cipher. CBC (Cipher Block Chaining) mode aims to make encryption non-deterministic by XORing plaintext with the previous ciphertext block.
  • An Initialization Vector (IV) is a random 16-byte value used for the first block in CBC mode. Servers are supposed to pick a random IV.
  • Tom chooses a constant IV (e.g., the plaintext data itself or simply zero). This makes the encryption of the first block deterministic.
  • Further "dumbness": He applies an algebraic relationship between the IV and data blocks, making subsequent blocks' encryption deterministic despite CBC mode.
  • He also ends the TLS record after the first encrypted block (16 bytes) to maximize the deterministic and visible nature of the encryption. This means a passive attacker can easily read the plaintext directly from packet captures.
• Exploiting TLS Extensions (Let's't Encrypt) [28:29]
  • TLS Session Tickets are an extension allowing clients to resume previous sessions faster by presenting a "ticket" that stores master secrets.
  • HTTPV implements session tickets by using the raw master secret itself as the ticket.
  • This "provably optimal" approach allows an attacker to intercept the (unencrypted) session ticket during the initial handshake, derive the master secrets, and then decrypt any subsequent traffic.
  • The server remains "stateless," as it doesn't need to store any session information.

System Limitations and Philosophical Reflections [31:07]

• OpenSSL's Max-Security Enforcement [31:07]
  • Tom highlights an issue where OpenSSL insists his server announce it doesn't support a specific, obscure TLS renegotiation bug (RFC 5746) even though his server doesn't have the bug.
  • OpenSSL refuses to connect if this announcement isn't made, which Tom interprets as "shaming" developers into unnecessary upgrades due to "toxic max-security."
• Cryptography is a Tool, Not an Enemy [32:20]
  • Tom clarifies that he loves cryptography and respects its power, having studied it extensively.
  • He proposes "Gymnography" (from Greek "gymnos" meaning naked) as a new subfield of computer science heresy.
  • Gymnography aims to counteract toxic max-security by deliberately "botching" security software and stripping formally applied cryptography, promoting transparent and intentionally imperfect security.
  • He invites academic contributions to this subversive field.
• Reflections on Security and Control [33:53]
  • Tom criticizes pervasive "security" measures that impose control and cost (e.g., Apple's App Store signing fees, RFID-tagged water filters).
  • He questions whether these "enforcers" of security are truly "good guys" and advocates for a careful and thoughtful approach to technology.