36

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?

  • 4
    The admin interface should always use TLS and proper authentication. This not only protects against bad internal actors but also anyone getting unauthorized access to your network (not just production network, but any network you access the production network from such as your company wifi). When you have to ask yourself whether TLS should be enabled, the answer is almost always "yes", there is little reason not to. – Marc Jun 5 at 10:03
  • 13
    Something to bear in mind is that there are different kinds of internal network. An office internal network is generally quite open - with low-privileged employees, visitors, ports in shared spaces, etc. TLS definitely recommended there. An internal network that only exists within a data center can be much more controlled. Although TLS is still recommended anyway. – paj28 Jun 5 at 16:09
  • Your ISP can sniff your LAN traffic remotely using the adsl/cable router. – CONvid19 Jun 6 at 16:15
  • A special case could be http2 support, which is often tied to https. So using TLS internally could be an easy way to enable http2 benefits for internal traffic – Falco Jun 6 at 17:41
  • 3
    I really don't mean for you to accept my answer specifically, but why in the world would you accept this copycat's answer that was added a day later than the ones they copied from? Accept zyk's or lab9's; the answer from "R.." (with some full caps political message in their username) added nothing new to the three existing posts. – Luc Jun 8 at 9:29
46

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.

| improve this answer | |
  • 3
    You have plenty of untrusted users you know are users too. The most likely adversary is an employee, either disgruntled or bribed by competition. – Jan Hudec Jun 8 at 6:32
  • -1 your answer adds no new info, three answers were posted a day before yours and included all the same info – Luc Jun 8 at 14:33
  • @Luc: I'm not sure if it adds new info, but it adds an important perspective. – R.. GitHub STOP HELPING ICE Jun 8 at 17:12
73

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

NSA intercepting Google traffic, writing "SSL added and removed here" with a smiley

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.

| improve this answer | |
  • 42
    I attended a talk by Bruce Schneier once where he described this slide. I believe his comment was "When the NSA makes a note about your network and adds a smiley face, that's not a good thing." – Seth R Jun 5 at 21:03
  • 13
    Note for the curious: This slide was accurate at the moment it became public, but nowadays Google encrypts based on physical boundaries instead of logical boundaries. There's (in general) no unencrypted DC-to-DC traffic on Google's network, except in cases where the DCs are close enough that the entire fiber between them is under Google's physical security and control (usually because they are part of a larger Google campus). – Kevin Jun 6 at 20:47
  • 6
    @Kevin "no unencrypted DC-to-DC traffic on Google's network, except..." given all the ways this can go wrong, as listed in the answer, that sounds like a recipe for disaster. – Luc Jun 6 at 23:57
  • @Luc: I don't work on the network, so I don't actually know about intra-campus DC-to-DC traffic. It's mostly transparent from the layer 7 perspective (and, as an SRE, I'm mostly operating at layer 8, anyway...). – Kevin Jun 7 at 0:01
  • 1
    @Kevin Just for the record, I didn't mean to pick on you or Google in particular; it was a very fair comment to make that Google fixed this in response to the leaks. The slide just illustrated the point. Still, I am surprised there is an "except" in that sentence rather than just making encryption ubiquitous, but I'm sure someone thought about the cost vs. benefits and this is just how it came out. – Luc Jun 7 at 17:26
10

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.

| improve this answer | |
7

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.
| improve this answer | |
4

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.

| improve this answer | |
  • using own internal CA to decrypt the traffic for monitoring is a very good point. – Architect Jun 8 at 8:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.