TLS Routing
You set up tls routing by reading the Server Name Indication header during handshakes. The router then sends encrypted packets to the matching backend service. Most platform teams use this method to share one public port across many apps. Still, network routing alone gives broad entry once a client passes the first check. Anyone who reaches the backend port can run full queries or commands without review. How native tls routing works in practice Standard network traffic uses certificates to p
TLS 1.3 Configuration + SNI-Based Routing Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up tls routing by reading the Server Name Indication header during handshakes. The router then sends encrypted packets to the matching backend service. Most platform teams use this method to share one public port across many apps. Still, network routing alone gives broad entry once a client passes the first check. Anyone who reaches the backend port can run full queries or commands without review.
How native tls routing works in practice
Standard network traffic uses certificates to prove identity and encrypt data in flight. When a client starts a session, it sends an initial hello message. This message holds the target host name in plain text inside the SNI field. The network router reads this host name before any encryption keys change hands. Based on that host name, the router picks the right internal server.
Teams choose between two main patterns when they build this flow. In passthrough mode, the router never decrypts the traffic stream at all. It simply forwards raw TCP packets straight to the target database or app server. The backend server then handles the TLS handshake and checks the client certificate. This keeps encryption end to end from the user to the target service.
In termination mode, the edge router holds the private key and ends the TLS session. The router decrypts the incoming stream and inspects the basic protocol headers. It then opens a fresh encrypted link or a plain link to the backend. Platform engineers like this pattern because they manage certificates in one central place. Both modes let many internal services share a single IP address and port.
What network routing solves and what it leaves open
Setting up tls routing solves IP exhaustion and reduces firewall rule sprawl. You do not need to open dozens of high ports on your edge load balancer. Instead, all traffic enters through one standard port and splits by host name. Mutual TLS adds another check by making sure the client holds a valid certificate. This blocks unknown machines from reaching your internal network ports.
Yet network routing and mutual TLS only decide who can open a socket. Once the TLS handshake finishes, the router steps out of the way. In passthrough mode, the router sees only scrambled bytes moving back and forth. Even with TLS termination, standard routers do not understand database protocols or shell commands. They cannot tell a safe read query from a command that drops a table.
TLS 1.3 Configuration + SNI-Based Routing Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Shared client certificates and static database passwords make this gap worse for teams. Engineers still need a database login or server key after the TLS check passes. Teams often hand out broad shared roles so developers can fix bugs fast. When an engineer runs a query, the database log only shows the shared role. You lose track of which person ran which command during an active session.
Inspecting live commands beyond the network layer
Closing this gap requires looking inside the session after the TLS handshake ends. Teams need controls that work at the command and query level, not just TCP. Every SQL statement or shell command should link back to an individual user identity. High risk actions should pause for a peer check before they run on production. Also, sensitive fields like emails, phone numbers, or card numbers need masking in results.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What is the difference between TLS passthrough and TLS termination?
TLS passthrough sends encrypted traffic straight to the backend server without reading the payload. TLS termination decrypts traffic at the edge router before sending it to the backend.
Does SNI routing work for databases as well as web apps?
Yes, modern database clients send the SNI header during the initial TLS handshake. Routers read this header to direct database sessions to the right internal cluster.
Can mutual TLS replace database user roles and query logs?
No, mutual TLS only checks that the client machine holds a trusted certificate. It does not control which SQL queries run or mask card numbers in results.