DNS Queries over HTTPS | Hacker News Reader

DNS Queries over HTTPS

tools.ietf.org

95 pointspierreneter67 comments

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.

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.

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.

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.

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”

> 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.

I agree with you. It's just the cards I am dealt.

> 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.

> 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.

If you control the IP address (or close enough), or DNS (or close enough) you simply ask letsencrypt to give you a new certificate.

You don't control either from the POV of LE verification infrastructure.

I certainly can. These kinds of takeovers occur all the time.

https://www.internetsociety.org/blog/2018/04/amazons-route-5...

https://www.itnews.com.au/news/china-systematically-hijacks-...

https://www.theregister.co.uk/2018/11/13/google_russia_routi...

My first experience with BGP hijacking was accidental and not malicious - and over twenty years ago now: I dropped Sprintlink off the East Coast US for several hours. If LE had been active, I could've taken over any Sprintlink-hosted (or downstream) SSL cert simply by performing challenges to LE. If people aren't doing this out of China and Russia I'd be surprised.

LE might mitigate this with multiple checks (across multiple private links) but it currently doesn't do this: LE checks my challenge only once.

>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:

Why not just have an internal forwarder that does DNS-over-HTTPS? Browsers would send traditional DNS to the forwarder, and the forwarder would do DoH from there.

This would also assume all the users would know how to configure this specific endpoint, or that IT staff do this for all the users. Today there isn't a good story around automating this process in heterogeneous shops. (windows, mac, linux, misc api tools)

If a browser has a default option to use CloudFlare, Google, Amazon or Microsoft, then the user will click the button to "secure their DNS" and suddenly their internal applications may break or do odd things and companies start leaking even more internal records.

Some IT departments may try to fix this by deploying configurations for 80% of the use cases and some may just block the public DoH servers.

I can think of many ways this could be solved. The point I was trying to convey is that people have not thought this through and implemented this in browsers before corporate infrastructure was ready to accommodate the need. This creates contention and friction that could have been avoided, in my opinion. Adoption is likely to be embraced more widely if more use cases are accommodated.

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.

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.

Certainly could. My assumption would be that the client implementation would have a way to exclude specific domains.

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.

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).

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.

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.

corollary question - if DNS data is not authenticated then how does the client distinguish between police and attackers?

much better to authenticate the policer.

Though, the data remains unauthenticated.

At least we get a private connection to a known entity though.

I'm kind of sad that we're using HTTPS as a transport though their use cases make sense. It seems this is intended to exist alongside the existing & new secure protocols? Is it foreseen that this will only be used by web apps?

Yes. No.