4 ms·

> Sending your DNS queries to a resolver that you control is hardly MITM. That's if your users are well-behaved and follow the rules. To stop the users from be

by vaduz 6y ago

> Sending your DNS queries to a resolver that you control is hardly MITM. That's if your users are well-behaved and follow the rules. To stop the users from being badly behaved, NSA recommends blocking connectivity to well-known IP addresses of the public DoH resolvers (e.g. Cloudflare) and TLS inspection to stop connections that try to go to less well known ones, including via ODoH, which means your TLS inspection device must understand the protocol. To do TLS inspection at that level you need to MitM all HTTPS traffic going everywhere, as you need to read all HTTPS traffic to any possible host, as any of them may be a DoH resolver or relay. Q.E.D.

deathgrips 6y ago
You seem to be implying that a company should not know what kind of web requests are coming from its computers.
- vaduz 6y ago
  > You seem to be implying that a company should not know what kind of web requests are coming from its computers. Please point out where I made that claim. All I am saying is that the way "knowing what kind of web requests" - and DNS request in this case - is achieved is by becoming a third party in supposedly two party encrypted communication. The company certainly has the authority to do so (check your local laws, though, as there are some exceptions) - but it is MitM in function and practice, if not in name. "TLS inspection" and "data loss prevention" are simply common euphemisms for the technique. It's also not new, MitM proxies and for that matter endpoint introspection (e.g. keyloggers at the user machine) have been in use for decades in the enterprise, and have been making their way into BYOD private machines as well via various MDM tooling. Using your company DNS server as the grandparent has mentioned is not MitM. Inspecting all traffic by all devices in your company to try to enforce the use of said DNS server requires MitM, though.
  - deathgrips 6y ago
    You keep saying MITM, which is an attack type, as if any kind of traffic inspection is bad. There is no third party in this sort of proxy: the company is communicating with the internet. The fact that a company proxy is inspecting traffic from a company computer does not make the company proxy a third party because both resources belong to the company and should be used for legitimate purposes. Is a reverse proxy doing a MITM attack on a web server if it offloads encryption and authentication for it? No, because both resources are owned by the same party. TLS inspection and DLP are not euphemisms, they're valid names for a security practice. They're not even the same thing--you couldn't replace both mentions with "MITM" and expect another to know what you're talking about.
nobody9999 6y ago
>To do TLS inspection at that level you need to MitM all HTTPS traffic going everywhere, as you need to read all HTTPS traffic to any possible host, as any of them may be a DoH resolver or relay. Q.E.D. Yep. And corporate/enterprise environments should (not nearly enough do) do exactly that with devices owned and managed by the enterprise. Any personal devices or those owned by contractors, clients and other external actors should not be allowed access to internal corporate networks. This is neither a particularly new or controversial idea either. Most large (or even medium-sized) organizations have separate "guest" networks for external resources which aren't secured or monitored. However, internal networks are (and should be) a very different story.
- vaduz 6y ago
  > Yep. And corporate/enterprise environments should (not nearly enough do) do exactly that with devices owned and managed by the enterprise. Sure! But the fact that they should (and many have been) already be doing just that does not change the fact that the technique imposes a third party listening into supposedly two party encrypted exchange. It's allowed, but it is still MitM. > Any personal devices or those owned by contractors, clients and other external actors should not be allowed access to internal corporate networks. This is neither a particularly new or controversial idea either. Whilst I agree, recent trend to push for more BYOD where the device is owned by the contrators, employee or an external actor, but still allowed access and controlled by the enterprise does tend to blur the lines quite a bit, especially as most tooling has been lacking decent isolation between "enterprise" and "private" on the same device. MDM tooling tends to want to administer the whole device and apply the stricter "enterprise" policies, with a pinky promise that private life is going to be respected.
  - nobody9999 6y ago
    >Whilst I agree, recent trend to push for more BYOD where the device is owned by the contrators, employee or an external actor, but still allowed access and controlled by the enterprise does tend to blur the lines quite a bit, especially as most tooling has been lacking decent isolation between "enterprise" and "private" on the same device. MDM tooling tends to want to administer the whole device and apply the stricter "enterprise" policies, with a pinky promise that private life is going to be respected. Which is why employees should either be given employer-owned devices or use device subsidies (as many companies provide) to pay for a device that's only used for work purposes. That companies attempt to hijack (and I mean that in both metaphorical and literal senses) personal devices for corporate purposes, aside from the obvious issues, it's also terrible security policy. That businesses do this is exploitative, unethical and insecure. I suspect such businesses don't really care about the first two, but should care about the third. As an infosec/infrastructure guy, I'd raise hell over such a policy -- because leaving aside the scumbaggery (I think I just coined a new word. Good for me!), having personal devices connected to internal corporate resources (even with corporate MDM configurations) is literally begging to be compromised, for (hopefully) obvious reasons.

by vaduz 6y ago

deathgrips 6y ago

You seem to be implying that a company should not know what kind of web requests are coming from its computers.

vaduz 6y ago
> You seem to be implying that a company should not know what kind of web requests are coming from its computers. Please point out where I made that claim. All I am saying is that the way "knowing what kind of web requests" - and DNS request in this case - is achieved is by becoming a third party in supposedly two party encrypted communication. The company certainly has the authority to do so (check your local laws, though, as there are some exceptions) - but it is MitM in function and practice, if not in name. "TLS inspection" and "data loss prevention" are simply common euphemisms for the technique. It's also not new, MitM proxies and for that matter endpoint introspection (e.g. keyloggers at the user machine) have been in use for decades in the enterprise, and have been making their way into BYOD private machines as well via various MDM tooling. Using your company DNS server as the grandparent has mentioned is not MitM. Inspecting all traffic by all devices in your company to try to enforce the use of said DNS server requires MitM, though.
- deathgrips 6y ago
  You keep saying MITM, which is an attack type, as if any kind of traffic inspection is bad. There is no third party in this sort of proxy: the company is communicating with the internet. The fact that a company proxy is inspecting traffic from a company computer does not make the company proxy a third party because both resources belong to the company and should be used for legitimate purposes. Is a reverse proxy doing a MITM attack on a web server if it offloads encryption and authentication for it? No, because both resources are owned by the same party. TLS inspection and DLP are not euphemisms, they're valid names for a security practice. They're not even the same thing--you couldn't replace both mentions with "MITM" and expect another to know what you're talking about.

nobody9999 6y ago

>To do TLS inspection at that level you need to MitM all HTTPS traffic going everywhere, as you need to read all HTTPS traffic to any possible host, as any of them may be a DoH resolver or relay. Q.E.D. Yep. And corporate/enterprise environments should (not nearly enough do) do exactly that with devices owned and managed by the enterprise. Any personal devices or those owned by contractors, clients and other external actors should not be allowed access to internal corporate networks. This is neither a particularly new or controversial idea either. Most large (or even medium-sized) organizations have separate "guest" networks for external resources which aren't secured or monitored. However, internal networks are (and should be) a very different story.

vaduz 6y ago
> Yep. And corporate/enterprise environments should (not nearly enough do) do exactly that with devices owned and managed by the enterprise. Sure! But the fact that they should (and many have been) already be doing just that does not change the fact that the technique imposes a third party listening into supposedly two party encrypted exchange. It's allowed, but it is still MitM. > Any personal devices or those owned by contractors, clients and other external actors should not be allowed access to internal corporate networks. This is neither a particularly new or controversial idea either. Whilst I agree, recent trend to push for more BYOD where the device is owned by the contrators, employee or an external actor, but still allowed access and controlled by the enterprise does tend to blur the lines quite a bit, especially as most tooling has been lacking decent isolation between "enterprise" and "private" on the same device. MDM tooling tends to want to administer the whole device and apply the stricter "enterprise" policies, with a pinky promise that private life is going to be respected.
- nobody9999 6y ago
  >Whilst I agree, recent trend to push for more BYOD where the device is owned by the contrators, employee or an external actor, but still allowed access and controlled by the enterprise does tend to blur the lines quite a bit, especially as most tooling has been lacking decent isolation between "enterprise" and "private" on the same device. MDM tooling tends to want to administer the whole device and apply the stricter "enterprise" policies, with a pinky promise that private life is going to be respected. Which is why employees should either be given employer-owned devices or use device subsidies (as many companies provide) to pay for a device that's only used for work purposes. That companies attempt to hijack (and I mean that in both metaphorical and literal senses) personal devices for corporate purposes, aside from the obvious issues, it's also terrible security policy. That businesses do this is exploitative, unethical and insecure. I suspect such businesses don't really care about the first two, but should care about the third. As an infosec/infrastructure guy, I'd raise hell over such a policy -- because leaving aside the scumbaggery (I think I just coined a new word. Good for me!), having personal devices connected to internal corporate resources (even with corporate MDM configurations) is literally begging to be compromised, for (hopefully) obvious reasons.