When internal hostnames are leaked to the clown

Original Article ↗ Hacker News Discussion ↗

Accessing the blog & blocking behavior

  • Several commenters report the blog being very slow or tar-pitted, especially via Apple Private Relay, some ISPs, and VPNs; oddly, Tor often works.
  • Others note the author has long blocked or throttled “bad” RSS clients, with some readers unsubscribing because the blocking felt over‑aggressive.

How the internal hostname leaked

  • Core interpretation: the NAS web UI includes Sentry JavaScript; the browser sends error/trace data (including the internal hostname) to sentry.io.
  • Sentry then appears to initiate TLS connections back to that hostname (for things like uptime checks, source maps, or icons), which are caught by a wildcard DNS/HTTPS “honeypot” the author set up.
  • Multiple commenters stress this is not a Certificate Transparency (CT) leak in this case, because only a wildcard cert was issued, not a cert for nas.….

Certificate Transparency, Let’s Encrypt & exposure

  • Some initially blame Let’s Encrypt/CT for making hostnames visible and attracting automated scanners (e.g., Heroku examples).
  • Others clarify that CT logging is effectively required for all public CAs, not specific to Let’s Encrypt, and wildcard certs only reveal *.example.com, not specific subdomains.
  • There’s anecdotal disagreement on whether LE‑issued domains are probed more than paid‑cert domains.

Severity of hostname leakage

  • One camp: internal hostnames can reveal sensitive metadata (e.g., merger names) and help attackers map internal networks; this is worth worrying about at high security levels.
  • Another camp: hostnames are inherently leaky (DNS, logs, emails, resolvers selling query data), so you should never rely on hostname secrecy; don’t put secrets in hostnames at all.
  • Suggested pattern: keep hostnames generic and put any “unguessable” part in the URL path instead.

Telemetry, Sentry, and browser-side tracking

  • Many see embedding Sentry in a “local appliance” web UI as an unacceptable, non-obvious privacy violation, especially on supposedly isolated LANs.
  • Others argue that once you give a device an IP stack and a browser-based UI, you shouldn’t be surprised if it phones home; vendors use third‑party telemetry to debug and prioritize features.
  • Some confusion initially blamed browsers or “mass surveillance,” later clarified as application-level JS behavior.

Defensive techniques

  • Common mitigations mentioned: uBlock Origin, Privacy Badger, router‑level blockers like AdGuard Home or Pi‑hole, DNS RPZ, Little Snitch, and injecting strict CSP and Referrer-Policy headers via a reverse proxy (e.g., Nginx) in front of appliances.
  • A few suggest honeypot hostnames or wildcard DNS to detect unexpected leaks.

NAS device choices and design philosophy

  • Mixed views on commercial NASes (especially Synology): some praise their stability when used purely as file servers; others dislike proprietary stacks, outdated kernels, phoning home, and difficulty with custom TLS.
  • Several advocate DIY Linux/TrueNAS-style boxes for control and transparency, while noting tradeoffs like power usage and extra setup effort.