Radius Over TLS
You set up radius over tls by wrapping login packets inside encrypted TCP sessions. Both the client device and the server check digital certificates before sharing data. Network teams often use this setup to replace older UDP login flows. Older flows only hide the password field and leave other packet data readable. When teams grant broad roles during login, users gain too much network reach. A valid login then lets an engineer run any command on target servers. How radius over tls works in yo
TLS 1.3 Configuration + Blast Radius Reduction: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up radius over tls by wrapping login packets inside encrypted TCP sessions. Both the client device and the server check digital certificates before sharing data. Network teams often use this setup to replace older UDP login flows. Older flows only hide the password field and leave other packet data readable. When teams grant broad roles during login, users gain too much network reach. A valid login then lets an engineer run any command on target servers.
How radius over tls works in your network
Standard RADIUS sends user login requests over UDP. It uses a shared secret to hide the password. The rest of the packet travels in plain text across the network. Anyone watching the wire can read usernames, device addresses, and role data. Radius over tls fixes this flaw by moving the traffic to TCP. This standard is also known as RadSec in many network tools.
First, the network switch or wireless controller opens a TCP link to the server. Next, both sides run a TLS handshake to check each other's identity. The client checks the server certificate against a trusted root authority. The server also checks the client certificate before accepting any login packets. Once the TLS tunnel is up, the client sends standard RADIUS frames inside it. This setup hides the whole packet from anyone watching the network path.
Setting up certificates and trust rules
To run this setup, your team needs a working certificate authority. You issue one certificate to the central login server. You also issue unique certificates to every switch, router, or VPN headend. Each device uses its private key to prove who it is during connect time. Using mutual TLS stops rogue devices from joining your login network. You no longer need to manage unique shared secrets for every single switch.
You can instead set a fixed shared secret required by the protocol standard. The real security comes from the TLS certificates and the encrypted tunnel. Teams must also plan how to rotate these certificates before they expire. If a certificate expires, the switch cannot check user logins anymore. Good certificate tracking keeps your network login flow running without surprise outages.
TLS 1.3 Configuration + Blast Radius Reduction: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What network login encryption solves and what it misses
Encrypting login traffic stops attackers from reading packets on internal networks or across WAN links. It makes sure that only trusted network gear can talk to your login server. It also keeps user attributes and group names private while they travel over the wire. This is vital when your login server sits in a cloud network.
Still, radius over tls only protects the initial login check. It decides who can log in to a switch, VPN, or server. It cannot see or control what that user does after the session starts. Once an engineer logs in with an admin role, the protocol steps aside. It cannot block a risky database query or a bad shell command. It also cannot rewrite sensitive fields like emails or card numbers in query results. Teams still need a way to check and log individual commands in flight.
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 main difference between standard RADIUS and RadSec?
Standard RADIUS runs on UDP and only hides the user password field. RadSec runs over TCP and wraps the entire packet inside a TLS tunnel.
Do I still need a shared secret with radius over tls?
Yes, the protocol standard still requires a basic shared secret value in the packet. Still, the TLS certificates provide the real security and trust between devices.
Does radius over tls record commands run during an admin session?
No, the protocol only handles the initial login check and role assignment. It does not watch or control individual commands or queries after login.