undefined | Better HN

0 pointsrossy9y ago0 comments

I think this SSL MITM thing has gone way too far. When an exec asks an engineer if it's possible to monitor all internet communication that goes in and out of the company network, including communication that is encrypted by TLS, the correct answer is no. In fact, this specific thing is what TLS is designed to prevent, and new implementations of the protocol are only going to get better at preventing it. The exec will only get the answer they want if they pressure the engineer, or if the engineer is trying to sell them something (like a MITM proxy.) Then the engineer will admit that it's possible to snoop on some TLS connections if you do awful things like installing fake certificates on company laptops. They may or may not mention that if they do it wrong it will degrade the security of everything on the network. God forbid the computers at a bank should be less secure than the computers in the average household because a MITM proxy is silently downgrading the security of all the TLS connections that travel through it.

Now, because engineers are so bad at saying 'no' to the people who want SSL MITM, it's apparently become a regulatory requirement. SSL MITM might let you passively surveil your employees' Facebook Messenger conversations, but it still doesn't protect you against a malicious employee who is tech-savvy (or malware written by people who have SSL MITM proxies in mind.) They could just put the information they want to smuggle out of the network into an encrypted .zip. They could even do something creative like using steganography to hide it in family photos that they upload to Facebook. The only real solution to this is to lock down the devices that people access the network on, not the network itself.

0 comments

7 comments · 2 top-level

semi-extrinsic9y ago· 3 in thread

> still doesn't protect you against (...) malware written by people who have SSL MITM proxies in mind

Exactly this is what I don't get. Since these abominations are becoming ubiquitous, surely malware writers are starting to work on workarounds? And in this case, it's as easy as setting up an SSH tunnel and running your malware traffic through that, which is a few days of work at best for a massive ROI?

cesarb9y ago

Not even malware writers: on the recent Cloudflare incident, there was one password manager which was affected, but the leak was harmless for them because the content within their TLS connections had another layer of encryption. Both MITM proxies and their TLS-terminating CDN can see only encrypted data.

wildmusings9y ago

Depending on the threat model and how serious you are about locking things down, you might just block all such traffic.

vidarh9y ago

In which case your malware can do DNS lookups against a suitable domain: Just chop your file into suitable sized strings, encode them as suitable hostnames and look up [chunk of file].evilmalwaredomain.com, and soon enough the server handling evilmalwaredomain.com will have the whole file.

Or plain HTTP POSTs with encrypted content. If it reject stuff that looks encrypted, plain HTTP POSTs encoding the binary files by taking a suitably sized file of words and encode it as nonsensical rants to a suitable user-created sub-reddit.

Or e-mails made using the same mechanism.

If you want low latency two way communication doing this can be a bit hard, but you basically have no way of stopping even a generic way of passing data this way unless you only whitelist a tiny set of trusted sites and reject all other network traffic (such as DNS lookups). And keep in mind you can't just lock down client traffic out of the network - you also would need to lock down your servers and filter things like DNS - the above mentioned DNS approach will work even through intermediary recursive resolvers (malware infected desktop => trusted corporate recursive resolver => internet), unless they filter out requests for domains they don't trust.

But basically, if you allow data out, it's almost trivial to find ways to pass data out unless the channel is extremely locked down.

wildmusings9y ago· 2 in thread

>In fact, this specific thing is what TLS is designed to prevent, and new implementations of the protocol are only going to get better at preventing it.

This isn't true. The TLS protocol is not a philosophy; it does not have an opinion on who you should trust as a root certificate authority. If you trust a particular root, it is wholly within the design of TLS to allow connections that are monitored by whoever controls that root authority. Who is trusted is up to you.

>They may or may not mention that if they do it wrong it will degrade the security of everything on the network.

Right, that's why you don't do it wrong. This same argument applies for any monitoring technology, like cameras. An insecure camera system actually helps a would-be intruder by giving them valuable information. So if you install cameras, you'd better do it right.

As for your list of ways such a system could be circumvented, I don't understand the logic of it. So because there are ways around a security measure, you shouldn't use the security measure at all? There is no security panacea, just a wide range of imperfect measures to be deployed based on your threat model and resources. And luckily, most bad guys are pretty incompetent. But to address some examples you give, and show how not all is lost:

- A large encrypted zip file is sent out of the network. Depending on what your concerns are, that could be a red flag and warrant further analysis of that machine's/user's activity.

- Software trying to circumvent your firewall/IDS is definitely a red flag. You might even block such detected attempts by default, and just maintain a whitelist for traffic that should be allowed regardless (e.g. for approved apps that use pinned certificates for updates).

fulafel9y ago

> > In fact, this specific thing is what TLS is designed to prevent, and new implementations of the protocol are only going to get better at preventing it.

> This isn't true. The TLS protocol is not a philosophy; [...]

Well, the TLS specification [1] says as the first sentence of the introduction:

"The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications."

I think, if something is "the primary design objective of TLS", it can be said that TLS is designed to do it.

[1] https://tools.ietf.org/html/rfc5246#section-1

rossyOP9y ago

> This isn't true. The TLS protocol is not a philosophy; it does not have an opinion on who you should trust as a root certificate authority. If you trust a particular root, it is wholly within the design of TLS to allow connections that are monitored by whoever controls that root authority. Who is trusted is up to you.

Like the sibling comment said, this goes against the wording of the TLS specification, but I also think this is looking at the issue from the wrong perspective: from the perspective of the network admin rather than the user. The user does not trust the MITM proxy's fake root. Let's say you set up a corporate network and rather than just whitelisting the external IPs you trust, you give your users the freedom to browse the internet but you pipe everything through a BlueCoat proxy. Your users will take advantage of this freedom to do things like, say, checking their bank balance. When the user connects to the banking website, they will initialize a TLS session, the purpose of which is to keep their communication with their bank confidential. The user will assume their communication is confidential because of the green padlock in their address bar and the bank will assume their communication is confidential because it is happening over TLS. TLS MITM violates these assumptions. If the bank knew that a third party could see the plaintext of the communication, they probably would not allow the connection. If I ran a high-security website, I'd probably look for clues like the X-BlueCoat-Via HTTP header and just drop the connection if I found any.

> As for your list of ways such a system could be circumvented, I don't understand the logic of it. So because there are ways around a security measure, you shouldn't use the security measure at all?

In some cases, yeah. There are a lot of security measures out there that are just implemented to tick some boxes and don't provide much practical value. If they don't provide much value, but they actively interfere with real security measures (for example, by delaying the rollout of TLS 1.3) or they're just another point of failure and additional attack surface (bad proxies can leak confidential data, cf. Cloudflare,) they should be removed. I'll admit most bad guys are incompetent, but it's dangerous to assume they all are, because that gives the competent ones a lot of power, and someone who is competent enough to know that a network uses a TLS MITM proxy will just add another layer of encryption. (Or, like some other comments are suggesting, they'll just test your physical security instead and try to take the data out on a flash drive.)

j / k navigate · click thread line to collapse