Just want simple TLS for your .internal network?

Original Article ↗ Hacker News Discussion ↗

Internal TLS with Name-Constrained CAs

  • Original idea: use a private CA constrained to a specific namespace (e.g., *.myhome.internal) so others can install the CA without risking MITM on arbitrary domains.
  • Some want similar constraints on existing third‑party CAs (e.g., government CAs) via cross-signing with name constraints, but note this requires additional setup and distribution of the cross-signed cert.

Name Constraints: Power vs. Reality

  • Name constraints are part of X.509 (since ~RFC 5280) but historically poorly implemented.
  • Older and some current clients may mishandle them or ignore parts (e.g., only SAN, not CN).
  • One comment notes existing audits (Netflix BetterTLS) didn’t fully test constraints at trust anchors.
  • Concern: relying on constraints assumes correct client behavior; not always true, especially on legacy or embedded devices.

Public CAs, ACME, and Internal Domains

  • Many prefer using a public CA (e.g., Let’s Encrypt) with DNS challenges:
    • Works for internal IPs.
    • Wildcard certs + a reverse proxy (Caddy, Nginx, Kubernetes ingress, etc.) simplify deployment.
  • Benefits: no need to distribute a private root across all OSes, apps, containers, and smart devices.
  • Downsides: public DNS/CT logs can reveal internal hostnames, which some see as low‑risk, others view as sensitive reconnaissance data.

Wildcard Certificates: Convenience vs. Risk

  • Wildcards via DNS‑01 are popular for internal networks.
  • Pros: one cert covers many hosts; easier automation.
  • Cons:
    • Any compromised host in the wildcard zone can impersonate any other.
    • Friends/family can’t easily detect abuse of a shared wildcard.
    • Some see this as “technical debt”; others consider it a practical trade‑off.

Threat Models and Why Use TLS Internally

  • Motivations:
    • Devices roaming onto hostile Wi‑Fi.
    • Protection against router or LAN malware, ARP spoofing, or shared networks.
    • Browser features and UX (clipboard APIs, warnings) require HTTPS.
  • Skeptics argue that if you fully trust all devices on your LAN, TLS adds little, but others counter that this level of trust is unrealistic in modern mixed‑device environments.

DNSSEC, DANE, and Related Debates

  • Some advocate DANE + DNSSEC as a decentralized alternative to ACME, especially for .internal.
  • Others respond that:
    • DNSSEC/DANE deployment is low and problematic (middleboxes, stripping, complexity).
    • Major email providers favor MTA‑STS over DANE.
    • There is disagreement over whether DNSSEC is “failing” or slowly growing; data and interpretations conflict.

Operational Pain of Private PKI

  • Repeated experiences: installing a custom root CA on diverse OSes, browsers, mobile devices, smart TVs, and containers is fragile and time‑consuming.
  • This pushes many toward public CA + DNS‑01 solutions despite privacy concerns.

Intentional MITM Use-Cases

  • Some explicitly want to MITM their own network (e.g., to filter/redirect YouTube for children).
  • Others note this aligns technically with what large network censors do, and that devices increasingly try to bypass local control via hard‑coded DNS and encrypted DNS.