Tunnl.gg

Original Article ↗ Hacker News Discussion ↗

Core Idea & UX

  • SSH-based localhost tunneling service: exposes HTTP/TCP/WebSockets from localhost to public internet.
  • No signup, no separate client; assumes an SSH client is already installed.
  • Aimed at low-friction dev sharing and testing, not production hosting.
  • Example shell function shows it can be one short command to expose a port.

Comparison to Alternatives

  • Seen as a simpler, no-account alternative to ngrok.
  • Compared to Cloudflare Tunnels, Tailscale Funnel, localtunnel, playit.gg, packetriot, etc.
  • Key differentiator: pure SSH, no extra binary; similar in spirit to serveo.net and other SSH-tunnel services.
  • Some argue a personal VPS + SSH reverse tunnel is just as easy and more controlled if you already have infra.

Security, Abuse & Misuse

  • Multiple commenters warn it will attract malware/data-exfiltration and C2 traffic.
  • Discussion of “data exfil routes” and how easy local hosting via tunnels is attractive for malware authors.
  • Other tunnel providers report that 2/3 of resource usage can be abusive; some had to shut down free services or remove TCP from free tiers.
  • Suggestions: portal/warning page like ngrok, endpoint scanning (e.g., nuclei), abuse-reporting pages, possibly restricting TCP.

Privacy, Logging & Encryption

  • Privacy policy initially vague about IP logging; clarified after feedback (especially EU/GDPR concerns).
  • Initial “end-to-end encrypted” claim was incorrect; TLS is terminated at the service and forwarded over plain HTTP to localhost.
  • SSH trust-on-first-use and lack of published host keys/SSHFP records raise MITM concerns.

Sustainability & Business Model

  • Service is free; costs are paid out-of-pocket. Author claims bandwidth is currently manageable.
  • Commenters worry about rug-pulls and ask for a paid tier or clear path to sustainability.
  • Author is open to monetization “for a few bucks” and/or open-sourcing if the project gains traction.

Technical Details & Future Plans

  • Uses a wildcard certificate for subdomains.
  • Single server listens on 22/80/443; tunnels are multiplexed over 443 and separated by subdomain, not port.
  • No IPv6 support yet.
  • Suggestions: public suffix list entry, cookie-isolating subdomain, caching/static-site add-ons, GitHub-keys-based lightweight auth, and self-hostable/OSS server with API keys.