What is the use case for using TLS on an internal network?

Question

If there are admin consoles on the internal network and TLS has been disabled what is the use case for enabling it?

The only use case I can think of is when you have untrusted users on the network who could potentially use pack sniffers to sniff the traffic.

Enabling TLS would mean monitoring devices would not able to monitor the traffic as it will be encrypted.

What are your thoughts? Should TLS be enabled for users accessing services (e.g. admin consoles) on internal networks?

Answer 1

The only use case i can think of is if you have untrusted users on the network...

This, but the problem is that you have untrusted users who you don't even know are users on the devices on network. This includes:

• Botnet nodes on compromised IoT junk
• Developers of whatever sketchy apps you installed on your phone or PC
• Attackers who've already compromised an actual server on your network, possibly a low-value one where security was overlooked
• Physical attackers who discretely connected a device to an ethernet jack somewhere
• Neighbors/wardrivers who guessed/brute-forced your wifi password
  • And any of the above using their devices
• Etc.

A fundamental principle of security is that the network layer is always untrusted. If you follow this you will save yourself a lot of trouble.

Answer 2

See the note in the bottom center of this classic slide:

This is from a leaked NSA slide deck. Tapping internal traffic is not rocket science, the only real requirement is that someone is targeting you. If there is something of value going over the cable, something potentially worth encrypting, then you may also assume that someone might be going after it sooner or later.

That's why we encrypt internal traffic: physical cables are not always to be trusted. A guest in a waiting room having access to the internal network (due to missing or misconfigured (V)LANs) is not uncommon, or someone who is trusted but whose device is infected, or someone who physically breaks in, or a single compromised server that can intercept other servers' traffic... there are a lot of scenarios in which encryption helps, also on internal networks. You should also ask yourself: is the least privileged person with physical (or network) access allowed to learn the most sensitive data that the network transports? If not, encryption is what ensures they can't intercept it.

Do you know where your physical cables run and whether all those places are guarded at all times? Is ARP spoofing disabled in every LAN you have? VLAN hopping mitigated? No WPA2-PSK WiFi anywhere? Intermediate firewalls and routers have 2FA enabled and are not hacked? Are all of the implemented measures tested? Did I not forget anything? From my experience, each of these measures is in use only in a minority of companies, and very few will have it all.

Setting up the encryption is typically easy these days. If you're only talking about your own data, then you can take the risk for yourself. But when there are other people (colleagues or even customers) at risk, you really should enable it.

Answer 3

With TLS enabled for internal services, you are reducing the risk against threats such as:

• Sensitive data disclosure through sniffing attacks against a malicious insider or an external attacker who already has a foothold inside your network
• Man-in-the-Middle attacks through rogue servers which can easily spoof the identify of an unauthenticated server (TLS gives you authenticity besides confidentiality*) which can then escalate to greater attack scenarios
• Unauthorised alterations of data in transit, which can cause serious damage if the data being sent is part of some administrative command (TLS also gives you the data integrity security service)
• Probably others that I can't think of right now...

* Assuming that it is not a self-signed TLS certificate and some sort of establishment of trust exists, such as an internal PKI.

As always, it's a risk-based approach. If you think the above threats are not far-fetched for your network/organisation, then I would recommend implementing TLS where possible internally. If for any reason this will add a layer of complexity that would outweight the gained benefits (as the risk of such threats materialising is deemed as low), then don't.

Answer 4

In my opinion, it's recommendable to secure sensitive internal sites with TLS.

The reasons:

• If an attacker has gained an initial low-privilege foothold on your network, she'd have a bigger attack surface (through packet sniffing and the like) to do privilege escalation if your admin pages weren't properly secured.
• It might be naive to exclude the possibility of malicious actors within the internal network.

Answer 5

Should TLS be enabled for users accessing services (e.g. admin consoles) on internal networks?

Yes.

You've already mentioned confidentiality against an internal bad actor on your network with a packet sniffer. That's enough of a reason right there. It could be a rogue employee, or a guest, or a compromised printer.

Let's talk about that printer. Lateral movement. Once someone "outside" gets a foothold on your network, they are now inside.

TLS also offer Integrity, as well as Confidentiality. It stops the bad-guy from changing the commands in-flight to the admin console.

Finally, TLS provides Authentication, at least of the server to the clients. It protects your users from going to fake phishing sites.

"internal" network perimeter should not be your only defense mechanism. This is the "defense in depth" idea.

Enabling TLS would mean monitoring devices would not able to monitor the traffic as it will be encrypted.

As for monitoring, you can deploy your own internal CA, sign the TLS certs with that, and have your own monitoring tools intercept and decrypt the traffic, if that's a requirement.