Let's Not Encrypt (2019)

Original Article ↗ Hacker News Discussion ↗

Tone of the article and irony

  • Many readers see the piece as perfectionist, contrarian, or borderline satire; others think it raises valid concerns about WebPKI, not about encryption itself.
  • The author’s later adoption of a Let’s Encrypt (LE) cert is noted as ironic and evidence that browser and ecosystem pressure make plain HTTP practically untenable.

Why “encrypt everything” became the norm

  • Commenters recall widespread pre-HTTPS abuse: ISPs injecting ads and banners into HTTP pages (including on paid business lines and metro Wi‑Fi), toolbar/AV software rewriting pages or even leaking banking sessions, and trivial session hijacking on public Wi‑Fi.
  • Several argue that without near‑universal TLS, ISPs and other intermediaries would still be routinely tampering with traffic, and mass surveillance would be easier.

Critiques of Let’s Encrypt and WebPKI

  • Core criticism repeated: if an attacker can MITM the ACME validation (HTTP‑01 or DNS‑01), they can get their own cert, so LE “doesn’t stop” that class of MITM.
  • Others add that DV certs authenticate only domain control, not real‑world identity; scammers can and do get valid certs, undermining the “identity” story.
  • Some worry about ecosystem fragility: constant TLS deprecations, short lifetimes, and browser policies break older devices (e.g., iDRAC/iLO), forcing use of outdated browsers.
  • Concerns also raised about concentration of power: CAs and browser vendors (esp. Google) effectively decide who is trusted; LE is funded mainly by large corporations.

Defenses of Let’s Encrypt and modern PKI

  • Multiple replies say the article gets facts wrong or omits context:
    • HTTP still loads in modern browsers (with “Not secure” indicators); only some domains (e.g., HSTS‑preload) must be HTTPS.
    • ACME challenges can be DNS‑based; certbot need not run as root; many stacks integrate ACME safely.
  • Attack model: MITM’ing a random café user is easy; MITM’ing LE from multiple global validation points is far harder, often requiring state‑level capability.
  • Certificate Transparency, CAA records, multi‑perspective validation, and short‑lived certs are cited as making mis‑issuance detectable and raising the cost of abuse.

Alternatives: self‑signed, TOFU, DNSSEC, DANE, SSH‑style

  • Some advocate trust‑on‑first‑use (SSH‑style pinning), self‑signed certs, or DNSSEC/DANE as simpler or less centralized.
  • Pushback: TOFU fails if the first connection is MITM’d; average users cannot safely compare fingerprints; DNSSEC is itself PKI with deployment and governance issues.
  • There is broad agreement that real‑world identity remains weakly solved, and that encryption and identity probably should be decoupled conceptually.

Operational trade‑offs

  • Short‑lived, automated certificates feel like “time bombs” to some, especially for small static sites that change rarely.
  • Others argue frequent automated renewal is safer than long manual renewals: failures surface quickly, processes are continuously exercised, and revocation/OCSP issues are eased.