HTTPS by default

Original Article ↗ Hacker News Discussion ↗

Testing HTTP and current browser behavior

  • Commenters mention tools like http.rip, neverssl.com, and example.com as ways to trigger HTTP flows or captive portals; some now use HTTPS first and then JS to load random HTTP subdomains to defeat automatic HTTPS upgrading.
  • Chrome already flags HTTP as “Not Secure,” with stronger warnings in Incognito and Advanced Protection. The announced change adds a blocking interstitial for HTTP navigations, with exceptions for private/internal sites. Localhost is treated as “secure” even without HTTPS.

HTTPS adoption and Linux/intranet usage

  • Discussion notes Linux’s lower HTTPS percentage is largely due to local dashboards and intranet UIs (phpMyAdmin, netdata, homelab services) typically running over HTTP.
  • When internal/private sites are excluded, Linux HTTPS usage jumps to ~97%, aligning with other platforms.

Home and intranet TLS challenges

  • Main friction points: getting certs for internal hostnames/IPs, running a private CA across heterogeneous devices (Android split trust stores, Firefox separate store), and certificate transparency exposing internal hostnames.
  • Workarounds include cheap public domains plus wildcard certs, DNS-based ACME challenges, or many small ACME clients; some see this as still too complex/paid for a “home intranet.”
  • Some argue HTTP on a “trusted LAN” is acceptable; others point to hostile IoT devices, ISP/neighbor access, and future WiFi breaks as reasons to encrypt internally too.

Arguments for HTTPS-by-default

  • Proponents emphasize: prevention of on-path tampering (ISP/hotel ad injection, captive-portal hacks), credential theft (Firesheep-era session hijacking), and pervasive surveillance (sensitive topics, political/medical browsing).
  • They stress that site owners can’t know a user’s threat model; even static blogs benefit from integrity and privacy.
  • Commenters say automation (ACME, Caddy, cloud/CDN integration) has made certificate management largely “set and forget.”

Critiques: complexity, centralization, and user control

  • Skeptics see increased dependence on CAs and browser vendors (especially Google/Chrome), more operational complexity (short cert lifetimes, rotation, tooling), and risk of future policy abuse (sanctions, attestation, CA consolidation).
  • Some object to forcing HTTPS even for trivial content, arguing this trains users to click through warnings and turns the open web into a more controlled, corporate ecosystem.
  • There’s concern that HTTPS hides traffic from device owners as well (harder to inspect what apps/big platforms are exfiltrating), while not stopping corporate or government MITM on managed devices.

Corporate MITM and captive portals

  • Several note enterprise setups that install a custom root CA and proxy all HTTPS, effectively MITM’ing employees; some see this as normalized, others as unacceptable or even illegal in some jurisdictions.
  • Captive portal vendors often still rely on HTTP-only redirects and even instruct admins to disable HTTPS before auth; commenters predict they’ll lag until breakage forces updates, despite better DNS/OS-level captive mechanisms existing.