5 ms·

I read that to mean: Do not allow doh to tunnel all your dns traffic out to cloudflare regardless of the promise of encryption. Send it only to the designated e

by belorn 6y ago

I read that to mean: Do not allow doh to tunnel all your dns traffic out to cloudflare regardless of the promise of encryption. Send it only to the designated enterprise DNS resolver, ie the one under control by the enterprise. All other DNS resolvers should be disabled and blocked, ie all those public dns resolvers.

salawat 6y ago
In other words "MitM everything". It gets so tiresome. I used to think the people who called out tyranny everywhere were just nuts, but it never ceases to amaze that everything nowadays keeps going "centralize and control".
- wmf 6y ago
  Sending your DNS queries to a resolver that you control is hardly MITM. In this case "you" is a company.
  - StreamBright 6y ago
    What he means is that NSA and related has the ability to MITM HTTPS while another actors do not, probably.
  - userbinator 6y ago
    ...and in the case of people using DNS-based adblocking and such, "you" is... yourself.
  - 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.
- VWWHFSfQ 6y ago
  No you're misunderstanding what the recommendation is. If a company runs their own DoH or even regular DNS or AD resolvers, then the company's client computers (the laptops their employees take home) should not be querying any old resolver hard-coded in their web browser (Firefox, CloudFlare) for internal company domain addresses. That's literally all this is saying. It's good corporate IT policy anyway and it's only being reiterated with DoH.
  - salawat 6y ago
    Oh, to be able to buy that anymore. I don't see anyone implementing it that way though. I see it being implemented in a way whereby all DNS activity must go through the corp resolver first, essentially giving full tracking history of 99% of users. Yes, it already happens with corporate proxies, and yes, I'm sour about that too... To be clear, I'm not blaming any NetOps here. It's just... Why is it so tempting? The things you can do with that type of data, it almost seems like you have to be superhuman in terms of keeping people away from it. Maybe I"m just too damn enchanted by just delivering packets to enable people... But when you get pushes from agencies suggesting "Hey, add a by definition awesome logging and tapping point" it really ruins my day. And yes, I run a network too. No. I don't give a darn what my users do with it as long as the servers are up and fine, and the global riffraff stay out. I don't know. Just overly grumpy I guess.
    - VWWHFSfQ 6y ago
      To be honest, I have no idea what point you're trying to make. Here it is: * Companies have internal (intranet) network services * Companies operate their own DNS (DoH) resolvers * They also have global (internet) employees * The devices those employees use have hard-coded DNS (DoH) resolvers (Google, CloudFlare) * Don't let them use the hard-coded DNS (DoH) resolvers * Make sure their machine uses the company DNS (DoH) resolver. I know people think that DNS-over-HTTP makes everything private and secure, but it doesn't. Google and CloudFlare still see every single DNS query from everyone.
    - deathgrips 6y ago
      >And yes, I run a network too. No. I don't give a darn what my users do with it as long as the servers are up and fine, and the global riffraff stay out. You don't care if your users get hacked? Would you mind telling me what company you work for?
- grayfaced 6y ago
  In light of SolarWinds hack, I think it's fair to say that DoH is a real threat. Putting that volume of machines under the control of a single "trusted" network provider is very bad idea.
- nobody9999 6y ago
  > In other words "MitM everything". >It gets so tiresome. I used to think the people who called out tyranny everywhere were just nuts, but it never ceases to amaze that everything nowadays keeps going "centralize and control". The recommendations are for enterprise networks, although they're also reasonable (although not really accessible to the non-technical) for individuals who care about their privacy as well. An enterprise network isn't (or shouldn't be) some sort of individual free-for-all. In fact, good security practice recommends (although this isn't universally implemented) that all perimeter network traffic, regardless of type, be proxied (or MitM'd, as you put it) to protect from both intrusions and exfiltration of data. Are you claiming that Enterprise networks should allow external resolvers to be used on internal resources willy-nilly? In fact, good security practice demands that devices that aren't authenticated (e.g., with 802.1x) shouldn't be granted access to internal resources at all. On the flip side, internal devices shouldn't rely on external infrastructure resources either. This isn't censorship or some sort of fascistic control mechanism. Rather, it's an appropriate organization response to extant and potential threats to their IT infrastructure and data.

by belorn 6y ago

salawat 6y ago

In other words "MitM everything". It gets so tiresome. I used to think the people who called out tyranny everywhere were just nuts, but it never ceases to amaze that everything nowadays keeps going "centralize and control".

wmf 6y ago
Sending your DNS queries to a resolver that you control is hardly MITM. In this case "you" is a company.
- StreamBright 6y ago
  What he means is that NSA and related has the ability to MITM HTTPS while another actors do not, probably.
- userbinator 6y ago
  ...and in the case of people using DNS-based adblocking and such, "you" is... yourself.
- 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.
VWWHFSfQ 6y ago
No you're misunderstanding what the recommendation is. If a company runs their own DoH or even regular DNS or AD resolvers, then the company's client computers (the laptops their employees take home) should not be querying any old resolver hard-coded in their web browser (Firefox, CloudFlare) for internal company domain addresses. That's literally all this is saying. It's good corporate IT policy anyway and it's only being reiterated with DoH.
- salawat 6y ago
  Oh, to be able to buy that anymore. I don't see anyone implementing it that way though. I see it being implemented in a way whereby all DNS activity must go through the corp resolver first, essentially giving full tracking history of 99% of users. Yes, it already happens with corporate proxies, and yes, I'm sour about that too... To be clear, I'm not blaming any NetOps here. It's just... Why is it so tempting? The things you can do with that type of data, it almost seems like you have to be superhuman in terms of keeping people away from it. Maybe I"m just too damn enchanted by just delivering packets to enable people... But when you get pushes from agencies suggesting "Hey, add a by definition awesome logging and tapping point" it really ruins my day. And yes, I run a network too. No. I don't give a darn what my users do with it as long as the servers are up and fine, and the global riffraff stay out. I don't know. Just overly grumpy I guess.
  - VWWHFSfQ 6y ago
    To be honest, I have no idea what point you're trying to make. Here it is: * Companies have internal (intranet) network services * Companies operate their own DNS (DoH) resolvers * They also have global (internet) employees * The devices those employees use have hard-coded DNS (DoH) resolvers (Google, CloudFlare) * Don't let them use the hard-coded DNS (DoH) resolvers * Make sure their machine uses the company DNS (DoH) resolver. I know people think that DNS-over-HTTP makes everything private and secure, but it doesn't. Google and CloudFlare still see every single DNS query from everyone.
  - deathgrips 6y ago
    >And yes, I run a network too. No. I don't give a darn what my users do with it as long as the servers are up and fine, and the global riffraff stay out. You don't care if your users get hacked? Would you mind telling me what company you work for?
grayfaced 6y ago
In light of SolarWinds hack, I think it's fair to say that DoH is a real threat. Putting that volume of machines under the control of a single "trusted" network provider is very bad idea.
nobody9999 6y ago
> In other words "MitM everything". >It gets so tiresome. I used to think the people who called out tyranny everywhere were just nuts, but it never ceases to amaze that everything nowadays keeps going "centralize and control". The recommendations are for enterprise networks, although they're also reasonable (although not really accessible to the non-technical) for individuals who care about their privacy as well. An enterprise network isn't (or shouldn't be) some sort of individual free-for-all. In fact, good security practice recommends (although this isn't universally implemented) that all perimeter network traffic, regardless of type, be proxied (or MitM'd, as you put it) to protect from both intrusions and exfiltration of data. Are you claiming that Enterprise networks should allow external resolvers to be used on internal resources willy-nilly? In fact, good security practice demands that devices that aren't authenticated (e.g., with 802.1x) shouldn't be granted access to internal resources at all. On the flip side, internal devices shouldn't rely on external infrastructure resources either. This isn't censorship or some sort of fascistic control mechanism. Rather, it's an appropriate organization response to extant and potential threats to their IT infrastructure and data.