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.

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.

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

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.

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.

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

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.

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.

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.

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”

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.