Item — HN Reader

I agree that it's perfectly valid, but disagree that it's necessary. Deploying proxies has costs - it obscures the endpoints of communication from sensor software and makes anomaly detection more difficult.

Richard Bejtlich's "Practice of Network Security Monitoring" has a chapter dedicated to the costs and benefits of proxy deployments; I recommend the book for a look at one coherent method of network security monitoring.

2 comments

> Deploying proxies has costs - it obscures the endpoints of communication from sensor software and makes anomaly detection more difficult.

It also establishes a single machine that sees all the plaintext of everything that should have been TLS encrypted from every machine on your network. It's like attacker catnip.

If an attacker is able to gain root access to your proxy, or inline with a TAP where your proxy is sending intercepted traffic to, you probably have much bigger problems.

> If an attacker is able to gain root access to your proxy, or inline with a TAP where your proxy is sending intercepted traffic to, you probably have much bigger problems.

Bigger problems than an attacker being able to decrypt and modify all of the TLS sessions in your company? If you have bigger problems than that then they've presumably spilled out of the realm of IT problems entirely and you're dealing with some kind of government lawyers or maybe a large uncontrollable fire.

Being able to decrypt and modify TLS sessions pales in comparison to being able to access your domain controller, or dump all your databases.

It really doesn't.

The attacker can pull credentials that any user uses on any webpage or other TLS-based connection. It's not the domain admin password or the database password, it's both, and the other ones too. Like the one the accountants type into the company's banking website.

TLS MITM is essentially the holy grail because there are so many overlapping ways to break into everything. If there is some password nobody has ever typed into a web admin portal then get their email credentials and do a password reset. Or use one of the apps that uses TLS to authenticate updates to push out a key logger. Or wait for a new attack to be published and block delivery of the patch. Or take advantage of being able to display anything you want on the company's internal website and start social engineering. On and on.

TLS under non-self-compromise circumstances provides reasonable security and is allowed through corporate firewalls, which means that everything uses it one way or another. Which means if you can compromise TLS then you can essentially compromise everything.

I understand your point, and acknowledge that TLS MitM is a major security threat, but my point is that if you're able to get deep enough into someone's network that you're able to intercept traffic between where it is passed to the interceptor and then re-encrypted, most information they could get from a MitM could also be obtained by pillaging the network through direct endpoint and server access. If they install malware on your workstation, they'll grab your admin panel and email credentials with ease; they don't need a MitM to do it.

You're right that a TLS MitM is one big way to make it easier for them to pivot and install malware, but there are many other ways they can do it, too, if they're on your internal network.

I think the pros of TLS interception outweigh the cons. You are exposing yourself to a little more risk once someone has already breached you, but you could say the same about other security products and procedures. For example, if you gained admin access to an endpoint agent like Carbon Black or Google Rapid Response, you can now deploy malware to every machine in the company. The pros of these endpoint monitoring tools outweigh the cons, though. You just have to architecture and protect them properly.

It only obscures it if you have a bad setup. Having records of structured proxy logs is fantastic. Without being able to disallow uncategorized and malicious sites, the infection rate at my company would probably triple. Without being able to inspect proxy logs on the fly through our SIEM, we'd have to request packet captures for every single potential incident, and hope the captures didn't roll over.

We also do a lot of anomaly detection on the proxy logs themselves. It does obscure NetFlow-based anomaly detection, and does create complications in the architecture, sure, but from my experience with them, the pros outweigh the cons if you set them up properly.