Security: Certificate Transparency & Automated Scanning

Last updated: March 20, 2026

If you run a tunnel (or any public-facing service) and notice unexpected traffic hitting your endpoints almost immediately, this page explains why that happens and what you can do about it.

1. Certificate Transparency & Public Exposure

Since 2018, all major browsers require that publicly trusted SSL/TLS certificates be logged in Certificate Transparency (CT) logs. This is an industry-wide standard — it applies to every Certificate Authority (Let's Encrypt, DigiCert, Sectigo, Google Trust Services, and all others), not just one provider, and not just tunnelto.

CT logs are public, append-only ledgers. Anyone can query them. Their purpose is to make certificate mis-issuance detectable — if a CA issues a certificate it shouldn't have, the CT log provides a public record that security researchers and domain owners can audit.

The practical consequence: every domain that receives a publicly trusted SSL certificate becomes publicly discoverable within minutes. Automated bots continuously monitor CT logs in real time, extract newly issued domain names, and begin scanning those domains immediately.

This is not a tunnelto-specific behavior. It happens to every website, every API, every service that uses a publicly trusted certificate — whether it's hosted on AWS, a home server, or a tunnel.

2. What This Means for Your Tunnels

When you create a tunnel with a public hostname (e.g. myapp.tunnelto.me or a custom domain), an SSL certificate is issued for that hostname. That certificate appears in CT logs, and automated scanners pick it up.

Within minutes of a tunnel going live, you can expect bots to probe for common vulnerabilities, including:

• Exposed .env files containing secrets or credentials
• Exposed .git directories leaking source code
• Admin panels at common paths (/admin, /wp-admin, /phpmyadmin)
• Default API endpoints and debug routes
• Open databases (MongoDB, Redis, Elasticsearch) on default ports
• Known CVEs in common frameworks and CMS platforms

This is normal internet background noise. Every public-facing service on the internet experiences this traffic. The difference with tunnels is that developers are often exposing local development services that weren't designed to face the public internet directly, which makes the scanning more consequential.

3. How to Protect Your Tunnels

Use tunnel authentication

tunnelto supports bearer token and Basic Auth on a per-tunnel basis. When enabled, every request to your tunnel must include valid credentials before it reaches your upstream service. Credentials are bcrypt-hashed on our side and never forwarded to your application.

This is the single most effective thing you can do. With auth enabled, automated scanners get a 401 response and move on. Your local service never sees the request.

Don't expose sensitive services without auth

If you're tunneling any of the following, enable authentication:

• Development databases or database admin tools
• Admin panels or dashboards
• Services running with default or no credentials
• Internal APIs not designed for public access
• File servers or directory listings

Keep your local environment clean

Even behind a tunnel, basic hygiene matters:

• Don't serve your project root directory — serve only the public-facing build or application
• Ensure .env, .git, and other sensitive files aren't accessible via your web server
• Disable debug modes and development endpoints before exposing a service publicly

4. Additional Security Features

tunnelto includes several security measures beyond tunnel authentication:

• SSH tunnel isolation: Each tunnel uses a dedicated SSH key with restricted authorized_keys options. No shell access, no port scanning — only the specific tunnel port is exposed.
• End-to-end TLS options: Choose client-side TLS termination so the server never sees your plaintext traffic. Or let the server handle certificates automatically.
• Per-tunnel authentication: Bearer token or Basic Auth on individual tunnels. Credentials are bcrypt-hashed and never forwarded to your upstream service.
• Tenant isolation: Users can only see and manage their own tunnels, domains, and traffic. Cross-tenant data leaks are blocked at every layer.

For more details, see the security overview on our main page.

5. Further Reading

• Certificate Transparency — official project site
• crt.sh — public CT log search engine
• MDN Web Docs — Certificate Transparency

Questions about security? Contact us at security@tunnelto.me.