4 ms·

Please forgive me if this has been covered. AFAIK it has not. Has anyone worked out how this will play nicely in corporate environments? i.e. avoiding leakin

Please forgive me if this has been covered. AFAIK it has not. Has anyone worked out how this will play nicely in corporate environments? i.e. avoiding leaking even more internal names, resolving internal systems first, etc? Or is it on IT departments to now customize the proxy settings for all browsers and API clients on all operating systems? I ask, because I know that most companies barely manage this on one browser, much less all of them. I am not in IT, but I am occasionally required to assist them and sometimes that requires capturing DNS requests for entire networks.

yjftsjthsd-h 8y ago
Correct me if I'm wrong, but I'm pretty sure that this is in fact designed to break that kind of arrangement. The problem is that the mechanics used for corporate monitoring are almost exactly the same mechanics used for your ISP spy on you or censor things. So yes, the end result is that we will need to move monitoring (and potentially blocking if you're doing that) onto the endpoints.
- lwheelock 8y ago
  Not necessarily, it depends on the egress architecture. There are ways to do corporate monitoring that cannot be done by your ISP. Web content filters (aka Proxies) in a transparent mode deployment that are not performing TLS interception would not be able to monitor these queries if wrapped in TLS. However, an explicit mode deployment and all 80/443 traffic enforced by an egress firewall through the proxy that was performing TLS interception can still monitor this traffic. In fact, even if you’re not brokering TLS, the GET method described can still leak the query (but not response) unless your client uses tunneling (ie. CONNECT method). ISPs can’t force you to use an explicit proxy, but corporations can.
  - LinuxBender 8y ago
    That is a challenge for us as well. Many of our partners use MitM proxies, but our privacy, compliance and legal teams will not approve the usage of them. We promote a work-life balance which means we allow people to use work resources for personal use. Culturally, that is great. It does create this conundrum however. The company does not want to be liable for intercepting personal and financial data that does not belong to us.
    - lwheelock 8y ago
      I know your pain. This is a big issue especially with GDPR kicking in. Security teams have competing directives. Board & Investors: “Prevent customer data exfiltration” Privacy / Legal: “Employee activity monitoring Violates our regulatory obligations” HR: “BYOD is essential to talent retention, cultural comfort, and workforce optimization” Employees: “I refuse to use VDI or Jump Hosts”
    - dingaling 8y ago
      > We promote a work-life balance which means we allow people to use work resources for personal use. Personally I think that is foolish and naive. Not just from privacy perspective but also liability and tax reasons. Postmen don't get to use the vans for personal errands, factory workers aren't permitted to run the machines to make t-shirts for themselves. Why are IT resources considered differently? If you want to permit WLB then tell employees that they are fee to use their personal smartphones and 4G plans.
      - LinuxBender 8y ago
        I agree with you. It's just the cards I am dealt.
- pilif 8y ago
  > The problem is that the mechanics used for corporate monitoring are almost exactly the same mechanics used for your ISP spy on you or censor things. I disagree. With SSL getting more and more widely deployed, corporate monitoring has no choice but to add re-encrypting proxies. In that case, all SSL sites you are visiting are signed by a company internal certificate which is more or less obvious depending on the browser (if you ask me, browsers don't make this nearly as obvious as they should) However, this kind of monitoring absolutely continues to work fine even if the browser is using DNS over HTTPS. What DoH does break though, is internal DNS resolution of internal intranet hosts. Those would obviously be corporate owned as they would obviously have a corporation specific domain anyways, so no MitM is needed anyways because the admin can just look at the traffic on the server side. This means that as DoH becomes more widely used, a corporation has only two options to continue to be able to allow users to connect to internal sites, both of which are worse from a security standpoint than the status-quo: * they could assign publicly resolvable names to all of their internal hosts. This is likely to cause issues with IDS systems which assume that to be a DNS reflection attack and it of course also means that they now have to leak internal names to the public which obviously isn't desirable. * they could deploy browsers with a modified configuration. Now most corporation already do that anyways to deploy their internal monitoring cert, but some smaller companies might not be interested in monitoring their users and right now they can ship original browser installers from their original source with their original config whereas in the future they will need to use group policies or custom installers, both of which are less trustworthy for a user than the default installers with the default config (who knows what that group policy / custom installer is doing alongside of configuring DoH). So while option 1 is worse for overall corporate security, option 2 is worse for security and trust for individual users when the corporation is not currently doing any monitoring. This security downgrade hurts even more in light of the fact that real SSL interception is not at all stopped by this, so already malicious actors can continue to be malicious, but good faith actors have to accept a significant downgrade in either user-trustworthiness or security. I do not think this is a fair trade-off.
  - yjftsjthsd-h 8y ago
    > real SSL interception is not at all stopped by this I wasn't aware that SSL interception was possible without a CA trusted by the victim, which is trivial in Enterprise and nigh-impossible elsewhere.
- jimktrains2 8y ago
  I think gp was concerned more with not leaking internal dns names as DoH isn't using the system resolver and hence requires each application to be configured individually to point to an internal DoH server.
  - LinuxBender 8y ago
    Exactly. If DoH included a change or extension to DHCP or could leverage an existing feature of DHCP, then this could be solved for corporate use. I would imagine something like the Proxy PAC "option wpad-url" using a different code to signify DoH. Even then, only browsers would be addressed by wpad. There would still need to be a mechanism to set DoH for non browsers. We would also need all OS providers to get in front of this and have a package that supports internal DoH easily. i.e. AD snap-in for windows AD controllers. Perhaps an extension to sssd and/or Unbound and/or dhcp for Linux. That needs to happen before all the browsers start supporting this.
  - lwheelock 8y ago
    Certainly could. My assumption would be that the client implementation would have a way to exclude specific domains.
- LinuxBender 8y ago
  You are correct and that is my point as well. I have yet to see a company that manages all proxy settings for all browsers, operating systems, API clients, etc. At least, not very well. Shops that are strictly windows can enforce this from AD. Everyone else will have to shim something in. We are a mix of Windows, Mac and Linux. Mostly Mac. Without a decent path forward, I could imagine that many corporations may go the heavy handed route of blocking all the known DoH resolvers. I envision IP and DNS lists like firehol and various RBL databases to eventually contain these if they do not already.
  - geocar 8y ago
    The place I work blocks all Internet access. If you want to visit a webpage, you need to use the http (clear) proxy. Most web pages are blocked, and if you need one unblocked you open a ticket and wait a week (or escalate).
    - LinuxBender 8y ago
      I've seen that too. One of our partners has such a stringent policy that the government of China allows them to entirely circumvent their "great firewall" with their own dedicated circuits. They track metrics on every single packet to and from anywhere. They essentially built their own world-wide ISP.
  - derefr 8y ago
    I worked for IBM a few years ago as a remote worker. Interestingly, they don't try to solve this problem (Intranet + managed settings for proxying out) at all. Instead, they have the opposite arrangement: even sitting in an IBM 'work center' (that you needed to use your employee key-card to access), you're actually just on the public Internet, and you need to use a VPN to reach the IBM Intranet. The VPN backend interacts with a backend that records the device-management (MaaS360) enrollment status of the device, so you can't get onto the Intranet unless your machine is conformant. And if you aren't connected over VPN to the Intranet, you may as well just be sitting in an Internet cafe with a regular laptop—there's no data available for you to exfiltrate.
patrickmcmanus 8y ago
corollary question - if DNS data is not authenticated then how does the client distinguish between police and attackers? much better to authenticate the policer.
- bluejekyll 8y ago
  Though, the data remains unauthenticated. At least we get a private connection to a known entity though.

yjftsjthsd-h 8y ago

Correct me if I'm wrong, but I'm pretty sure that this is in fact designed to break that kind of arrangement. The problem is that the mechanics used for corporate monitoring are almost exactly the same mechanics used for your ISP spy on you or censor things. So yes, the end result is that we will need to move monitoring (and potentially blocking if you're doing that) onto the endpoints.

lwheelock 8y ago
Not necessarily, it depends on the egress architecture. There are ways to do corporate monitoring that cannot be done by your ISP. Web content filters (aka Proxies) in a transparent mode deployment that are not performing TLS interception would not be able to monitor these queries if wrapped in TLS. However, an explicit mode deployment and all 80/443 traffic enforced by an egress firewall through the proxy that was performing TLS interception can still monitor this traffic. In fact, even if you’re not brokering TLS, the GET method described can still leak the query (but not response) unless your client uses tunneling (ie. CONNECT method). ISPs can’t force you to use an explicit proxy, but corporations can.
- LinuxBender 8y ago
  That is a challenge for us as well. Many of our partners use MitM proxies, but our privacy, compliance and legal teams will not approve the usage of them. We promote a work-life balance which means we allow people to use work resources for personal use. Culturally, that is great. It does create this conundrum however. The company does not want to be liable for intercepting personal and financial data that does not belong to us.
  - lwheelock 8y ago
    I know your pain. This is a big issue especially with GDPR kicking in. Security teams have competing directives. Board & Investors: “Prevent customer data exfiltration” Privacy / Legal: “Employee activity monitoring Violates our regulatory obligations” HR: “BYOD is essential to talent retention, cultural comfort, and workforce optimization” Employees: “I refuse to use VDI or Jump Hosts”
  - dingaling 8y ago
    > We promote a work-life balance which means we allow people to use work resources for personal use. Personally I think that is foolish and naive. Not just from privacy perspective but also liability and tax reasons. Postmen don't get to use the vans for personal errands, factory workers aren't permitted to run the machines to make t-shirts for themselves. Why are IT resources considered differently? If you want to permit WLB then tell employees that they are fee to use their personal smartphones and 4G plans.
    - LinuxBender 8y ago
      I agree with you. It's just the cards I am dealt.
pilif 8y ago
> The problem is that the mechanics used for corporate monitoring are almost exactly the same mechanics used for your ISP spy on you or censor things. I disagree. With SSL getting more and more widely deployed, corporate monitoring has no choice but to add re-encrypting proxies. In that case, all SSL sites you are visiting are signed by a company internal certificate which is more or less obvious depending on the browser (if you ask me, browsers don't make this nearly as obvious as they should) However, this kind of monitoring absolutely continues to work fine even if the browser is using DNS over HTTPS. What DoH does break though, is internal DNS resolution of internal intranet hosts. Those would obviously be corporate owned as they would obviously have a corporation specific domain anyways, so no MitM is needed anyways because the admin can just look at the traffic on the server side. This means that as DoH becomes more widely used, a corporation has only two options to continue to be able to allow users to connect to internal sites, both of which are worse from a security standpoint than the status-quo: * they could assign publicly resolvable names to all of their internal hosts. This is likely to cause issues with IDS systems which assume that to be a DNS reflection attack and it of course also means that they now have to leak internal names to the public which obviously isn't desirable. * they could deploy browsers with a modified configuration. Now most corporation already do that anyways to deploy their internal monitoring cert, but some smaller companies might not be interested in monitoring their users and right now they can ship original browser installers from their original source with their original config whereas in the future they will need to use group policies or custom installers, both of which are less trustworthy for a user than the default installers with the default config (who knows what that group policy / custom installer is doing alongside of configuring DoH). So while option 1 is worse for overall corporate security, option 2 is worse for security and trust for individual users when the corporation is not currently doing any monitoring. This security downgrade hurts even more in light of the fact that real SSL interception is not at all stopped by this, so already malicious actors can continue to be malicious, but good faith actors have to accept a significant downgrade in either user-trustworthiness or security. I do not think this is a fair trade-off.
- yjftsjthsd-h 8y ago
  > real SSL interception is not at all stopped by this I wasn't aware that SSL interception was possible without a CA trusted by the victim, which is trivial in Enterprise and nigh-impossible elsewhere.
jimktrains2 8y ago
I think gp was concerned more with not leaking internal dns names as DoH isn't using the system resolver and hence requires each application to be configured individually to point to an internal DoH server.
- LinuxBender 8y ago
  Exactly. If DoH included a change or extension to DHCP or could leverage an existing feature of DHCP, then this could be solved for corporate use. I would imagine something like the Proxy PAC "option wpad-url" using a different code to signify DoH. Even then, only browsers would be addressed by wpad. There would still need to be a mechanism to set DoH for non browsers. We would also need all OS providers to get in front of this and have a package that supports internal DoH easily. i.e. AD snap-in for windows AD controllers. Perhaps an extension to sssd and/or Unbound and/or dhcp for Linux. That needs to happen before all the browsers start supporting this.
- lwheelock 8y ago
  Certainly could. My assumption would be that the client implementation would have a way to exclude specific domains.
LinuxBender 8y ago
You are correct and that is my point as well. I have yet to see a company that manages all proxy settings for all browsers, operating systems, API clients, etc. At least, not very well. Shops that are strictly windows can enforce this from AD. Everyone else will have to shim something in. We are a mix of Windows, Mac and Linux. Mostly Mac. Without a decent path forward, I could imagine that many corporations may go the heavy handed route of blocking all the known DoH resolvers. I envision IP and DNS lists like firehol and various RBL databases to eventually contain these if they do not already.
- geocar 8y ago
  The place I work blocks all Internet access. If you want to visit a webpage, you need to use the http (clear) proxy. Most web pages are blocked, and if you need one unblocked you open a ticket and wait a week (or escalate).
  - LinuxBender 8y ago
    I've seen that too. One of our partners has such a stringent policy that the government of China allows them to entirely circumvent their "great firewall" with their own dedicated circuits. They track metrics on every single packet to and from anywhere. They essentially built their own world-wide ISP.
- derefr 8y ago
  I worked for IBM a few years ago as a remote worker. Interestingly, they don't try to solve this problem (Intranet + managed settings for proxying out) at all. Instead, they have the opposite arrangement: even sitting in an IBM 'work center' (that you needed to use your employee key-card to access), you're actually just on the public Internet, and you need to use a VPN to reach the IBM Intranet. The VPN backend interacts with a backend that records the device-management (MaaS360) enrollment status of the device, so you can't get onto the Intranet unless your machine is conformant. And if you aren't connected over VPN to the Intranet, you may as well just be sitting in an Internet cafe with a regular laptop—there's no data available for you to exfiltrate.

patrickmcmanus 8y ago

corollary question - if DNS data is not authenticated then how does the client distinguish between police and attackers? much better to authenticate the policer.

bluejekyll 8y ago
Though, the data remains unauthenticated. At least we get a private connection to a known entity though.