Summary of "No one can force me to have a secure website!!!"

Summary — “No one can force me to have a secure website” (Tom7)

High-level theme

A critique of an overly aggressive browser security posture (what Tom calls “toxic max security”) that shames site operators and frustrates users. Wrapped around that critique is a playful engineering project: build an intentionally insecure HTTPS endpoint that nevertheless gets a green padlock in real browsers to prove a point.

Key technical concepts explained

HTTP vs HTTPS / TLS
- TLS is used to stop man‑in‑the‑middle attacks by using certificates issued by trusted Certificate Authorities (CAs).
- A high‑level TLS handshake:
  1. ClientHello
  2. ServerHello (including server random)
  3. Certificate presentation
  4. Premaster secret exchange
  5. Key derivation and symmetric AES encryption
Certificate Authorities and the trust model
- Root CAs are bundled into browsers and OSes; this centralization means many diverse entities are implicitly trusted.
- Let’s Encrypt changed the ecosystem by offering free, automated issuance, but it enforces rules via automated validation.
ACME / Let’s Encrypt validation
- The common HTTP token (ACME) challenge proves domain control by expecting a token at a well‑known URL over HTTP.
- Because ACME uses unencrypted HTTP for validation, an attacker with the ability to manipulate traffic can potentially obtain certificates—this highlights a tension in the model.
TLS primitives and common configuration choices
- RSA: key generation (n = p * q), common public exponent 65537.
- AES‑CBC: requires unpredictable IVs to avoid deterministic encryption and replay/dictionary attacks.
- Session tickets: used for session resumption; typically encrypted server‑side but can be abused if misused.
Vulnerabilities and operational details
- OpenSSL has had serious vulnerabilities; some clients (curl/OpenSSL) refuse to connect to servers that advertise legacy/unsafe renegotiation.
- Client safety checks can block access to servers with legacy or unusual behaviors.

The project: HTTPV (HTTP Vulnerable / “vulnerable” TLS reverse proxy)

Purpose: a TLS reverse proxy that:

Presents a valid certificate accepted by browsers (green padlock).
Is intentionally insecure with respect to data confidentiality (not intended to enable remote code execution).
Is implemented without OpenSSL and “without cheating” (the insecurity is at protocol level, not by exfiltrating secrets out‑of‑band).

Goals and constraints:

Must work in real browsers (so browsers show the secure icon).
Only leak public site content (not designed to break into hosts).
Home‑rolled implementation for the sake of making the point and for fun.

Design choices that make HTTPV insecure (intentional)

Weak / malformed RSA keys
- Multi‑prime modulus (Tom used a 16‑factor modulus). Let’s Encrypt will issue a cert for a large modulus, but such a modulus can be practical to factor with modest resources.
- Note: partial factor discovery can allow decryption; full factorization is needed for signing/revocation.
Reused / deterministic randomness
- Server and client random values are fixed across connections, defeating anti‑replay and key uniqueness guarantees.
Broken AES‑CBC usage
- IV chosen deterministically (e.g., equal to plaintext).
- TLS records truncated to a single AES block, leading to easily recoverable plaintext and predictable ciphertext patterns.
Session ticket misuse
- Session tickets contain raw master secrets in a stateless server design; because tickets are presented during the handshake (and can be forged), an attacker can craft tickets to derive arbitrary session keys or resume others’ sessions.
Miscellaneous
- “Full Heartbleed support” as an Easter‑egg — intentionally reintroducing famous weaknesses.

Operational notes & observed behavior

HTTPV has been serving tom7.org for months and was used with a Secret Santa app to generate screenshots showing the padlock.
Some clients/tools (for example, curl on a fresh Linux) refuse to connect because OpenSSL client checks around legacy renegotiation detect the unusual server behavior—not because HTTPV tries to exploit them. This highlights how client behavior and alarming messages can block access to legacy or intentionally unusual servers.
Let’s Encrypt checks for extremely small primes up to a small bound (e.g., 757) and rejects trivially small primes (p = 7). Multi‑prime moduli can evade those simple checks while still being weak.

Analysis and arguments

Toxic max security harms usability
- Aggressive, scary browser warnings (e.g., “attackers might be trying to steal your info”) are disproportionate for purely public, read‑only sites and push people toward opaque solutions (CDNs, vendor lock‑in).
Security theater and extortion concern
- The CA / bundled‑roots model creates incentives where inclusion in trust stores is valuable; CDNs and TLS termination services can hide operator inaction but introduce dependencies and costs.
Hypocrisy in defense
- Requiring operators to prevent attacks that, if successful, could bypass the very checks used to prove integrity (for example, ACME over HTTP) is potentially hypocritical.
A plea for balance
- Cryptography is powerful and valuable, but practitioners should avoid overreach. Tom jokingly proposes a tongue‑in‑cheek subfield, “gymnography” (naked crypto), to counterbalance “toxic max security.”

Quote (example of browser messaging)

“attackers might be trying to steal your info”

References, resources & guides mentioned

Tom’s 25‑page paper: full details and enhancements to the BOVX tool, plus the detailed design and implementation of HTTPV.
Previous video on public‑key cryptography (background on RSA).
Real‑world services/options discussed:
- Let’s Encrypt (ACME protocol)
- Cloudflare and other CDNs (TLS termination / proxying)
- OpenSSL (library with past vulnerabilities)
- curl/OpenSSL client behavior (compatibility / renegotiation issues)
Historical bugs referenced as examples / Easter‑eggs: Heartbleed, etc.

Product / features / demos

HTTPV project
- Presents browser‑accepted certificates.
- Demonstrates concrete protocol‑level ways TLS can be (mis)configured.
- Runs without OpenSSL.
- Intentionally enables easy decryption, replay, and resumption.
Live examples
- Tom’s public site served via HTTPV and a Secret Santa app used as demo content.

Practical takeaways

Browser warnings and CA trust models have real usability and political consequences; automatic hard failures can be disproportionate.
ACME / Let’s Encrypt made HTTPS ubiquitous, but automation relies on network conditions and introduces attack/abuse considerations.
Protocol configuration matters: poor randomness, incorrect IV use, deterministic records, and inappropriate session ticket handling can undermine TLS even with “valid” certificates.
Rolling your own TLS is discouraged in production, but a home‑built vulnerable implementation can illustrate systemic weaknesses and provoke discussion.

Main speakers / sources

Tom7 — presenter, author of HTTPV and the 25‑page paper (primary narrator).
Let’s Encrypt — discussed extensively as the CA and for ACME validation behavior.
Chrome product team / browser security UI — critiqued for alarming messages.
OpenSSL — mentioned for vulnerabilities and client behavior (curl interactions).
Brené Brown — cited for a quote on shame and vulnerability (TED talk).
Secondary mentions: Cloudflare (CDN/TLS termination), Heartbleed (historical bug), and friends Reed and Matt (anecdotal contributors).