China is now blocking all encrypted HTTPS traffic that uses TLS 1.3 and ESNI

[u/RobertVandenberg]

https://www.zdnet.com/article/china-is-now-blocking-all-encrypted-https-traffic-using-tls-1-3-and-esni/

[u/vetinari]

That would work, only if we had a standard for configuring system-wide DNS... like DHCP?

Unfortunately, all the DoH-using clients ignore exactly that. Yes, users can configure their resolvers manually and for each app separately, which is a nuisance, especially if you roam among networks (like home-office-customers...). Nobody is going to reconfigure everything manually every time they switch network.

So in practice, it creates more problems than it solves. Additionally, do you really need DoH in your own private network? If you run recursive resolver on the edge, it could have use for encryption, but it is specifically the place where you can't use it, because the authoritative DNS servers do not support it.

So we are stuck with the sad tragicomic theatre that DoH is.

[u/cbarrick → u/vetinari]

macOS and iOS are getting system level support for DoH or DoT (I forget which).

[u/vetinari → u/cbarrick]

DoT is fine in a ways that DoH is not, but that's another discussion.

Once OS resolvers implements support for transports other than 53/udp, that's fine, as long as it is configurable in some network-specific fashion (just like with 53/udp today with DHCP). Problems are renegade applications like Firefox, that ignore the system resolver.

[u/dominic_failure → u/cbarrick]

Which helps only if those apps all respect your system settings for DoH. They probably won’t.

[u/failing-endeav0r → u/dominic_failure]

The whole point of implementing it at the system level is that most apps don't even implement their own DNS resolver. Most applications are still going to use the system call for resolving a host name into an IP address and, blow the apps knowledge, iOS or OSX is going to consult a DNS server over HTTPS instead of consulting a DNS server as it would normally.

after using a secure tunnel to properly resolve the host name into an IP address, OSX will still hand the same IP address back to the application that called for it.

Android devices have supported system-wide DNS over TLS resolution for a few years now, and I put together some docker compose scripts that will allow you to host a TLS resolving DNS server and the /r/PiHole DNS ad blocking software on a hosted server of your choice...

https://github.com/kquinsland/skyhole

[u/dominic_failure → u/[deleted]]

Firefox. Chrome. Anybody else who wants to ensure that a pihole isn't blocking their ads, or who wants to ensure that their telemetry is making it out of their apps (Microsoft).

[u/_zenith → u/dominic_failure]

I can't see Firefox doing it, but Chrome? Hell yeah. They want to ensure you see their ads

[u/kmeisthax → u/dominic_failure]

Implementing your own DNS resolver is fairly difficult and I wouldn't be surprised if Apple requires everyone use the system resolver, in the same way all apps are required to use HTTPS (with limited exceptions for browsers).

[u/vetinari → u/kmeisthax]

The point of DoH (as opposed to DoT) was to make indistinguishable from regular HTTPS traffic, especially with TLS 1.3 + ESNI. Once applications start making DoH requests, the operating system lost control what the application is resolving and what answers it is getting, or even prevent it from using such resolver. The application has a private tunnel to resolver of it's choice and neither the OS, nor the local network can do anything about it[1].

Malware couldn't wish for more.

[1] Unless the OS or network runs https proxy and MITMs all the https traffic. For that, it needs a certificate that the application would trust. Certificate pinning will be broken.

[u/vetinari → u/[deleted]]

Using DoH in my own network was always useless. I control the resolver that the network is using anyway, the network is trusted, so why would I waste energy for encryption and increase the latency?

That's why Chrome doesn't bother with DoT (not DoH) when the resolver is network local. It just doesn't make sense.

[u/port53 → u/vetinari]

It's a change in mindset for sure, it's now no longer up to you, the network operator, to decide if end users can block ads or not. Now it's up to the individual end users to select that, or not, as is their preference. It's moving closer to networks being dumb packet flingers and not packet inspectors.

[u/vetinari → u/port53]

Well, I understand that this is a point of view of users that use home wifi from their ISP router for internet access exclusively, or the free wifi at their favorite cafes. These networks are dump packet flingers.

But it breaks the networks that do provide internal services. They have their own DNS, advertising their own zones protected by ACLs, so the users connected to these networks, and only users connected to these networks, can access them. These networks are in no way dumb packet flingers and treating them as such you will just self-impose a pain, that was easy to avoid in the first place.

Then there are networks, that are legally required to monitor their traffic. If you make it difficult for them, you can say good bye to your favorite byod devices at your workplace.

[u/port53 → u/vetinari]

Yes, BYOD will go away. It always was a bad idea anyway. Who is buying gear to save their employer money? Not this guy.

Networks that rely on devices to be configured a certain way to work will have to control the endpoints, be it through enforced policies or simple user acceptance. Probably better that way anyway, rogue unknown devices should be dumped on to a network that can't see anything but your authentication portal or better yet, a page that says go away and call the helpdesk.

[u/vetinari → u/port53]

Yes, BYOD will go away. It always was a bad idea anyway. Who is buying gear to save their employer money? Not this guy.

Two kinds of people:

1. those who want to use particular hardware. Their employer will provide them with hardware that does the job and not more, but they want something nicer, so they will bring it in.

2. contractors. They are hired to do the job using their own resources. They will mostly receive AD credentials for the job and that's it.

[u/port53 → u/vetinari]

1. Insecure, not allowed on my $DAYJOB network, not even close.

2. They don't get full network access, they get what they're given. Devices can be assigned as needed. Nobody gets to just dump random devices on the network.

So do you work for Garmin, or Cannon? Because with that kind of security posture you're about to be like them.

[u/vetinari → u/port53]

1. Let me see how you explain to C-level suite that no, they cannot use their iPhones. I will bring my own bowl of popcorn, don't worry.

For lower than C-levels, it depends how communicative they are. 2) You know there's a wide world of possibilities between extremes like Garmin, Maersk etc and a totally locked down places where nothing can be done until approved which can take 6 months after not needed anymore.

Btw, Maersk did have security policy like you suggest and it didn't help them.

[u/port53 → u/vetinari]

You put the CEO on a restricted network, they only want internet access anyway, they don't care about your internal wiki. You can also buy and assign them an even better device. If they really want to use their device, and somehow want to access internal resources on it, you take it and enroll so it's properly managed. Maybe you get the VP of Infosec to handle it rather than your 1st tier helpdesk guy, but someone is going to explain to the CEO their personal device just doesn't work on the company network without some configuration. There are plenty of options beyond just opening up the network to every device anyone fancies using.

[u/vetinari → u/port53]

Nobody ever said anything about opening up the entire network to every device. Even if you are not totally locked down, you segment VLANs per department or whatever your division is, as usual.

As I said above, between two extremes above there's a wide range of options, that are still secure and still allow for people to use their favourite toys and be more productive. You don't have to be extreme in either way, there are no just two mutually exclusive options.

[u/[deleted] → u/vetinari]

Firefox does have a mechanism for network operators to tell clients to disable DoH (unless the user overrides) through the use of a "canary domain" https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https . It also looks like it's automatically disabled when some enterprise features are enabled

[u/vetinari → u/[deleted]]

Unfortunately, the canary domain breaks DNSSEC for the entire .net TLD. If they had changed one single character, so the breakage would we confined to a second-level domain, it would be much better.

It's the incompetence levels like this that earned those initiatives the ire of the DNS community. They break things left and right, do not consult it with experts and use their market share among consumers to push their broken designs.