Improving DNS Privacy with Oblivious DoH

https://blog.cloudflare.com/oblivious-dns/

by websirnik • 6 years ago

541 349 6 years ago

blog.cloudflare.com

TimWolla4• 6 years ago

Probably better source, the blog post at Cloudflare: https://blog.cloudflare.com/oblivious-dns/

aorth• 6 years ago

Thanks. The original post redirects to:

https://guce.advertising.com/collectIdentifiers?sessionId=3_...

Which is blocked at the DNS level on my network.

jessmay• 6 years ago

As it should be.

dang2• 6 years ago

Thanks! we've changed to that from https://techcrunch.com/2020/12/08/cloudflare-and-apple-desig....

seek3r• 6 years ago

I’m good with the Apple’s privacy-oriented stance. But I can’t stop to think what will happen when advertisers knock on Apple’s door trying to get their hands on the users’ data that one else can access. Is Apple going to sell it out for more profits?

techelite3• 6 years ago

It's just marketing. Apple has already shown they will sell you out with PRISM.

Who knows what other backroom deals are happening outside our knowledge. The only reason we found out about PRISM is because the gigantic scale and Snowden sacrificed Everything to let it be known.

saberience• 6 years ago

I think there's a big difference between selling data for profit and the government literally forcing you to give up data based on national security laws or else forcing you to close your business. There's almost nothing Apple can do about the latter case (or any other company for that matter).

arminiusreturns• 6 years ago

One thing I like to remind people of is the fact that the Snowden docs that revealed PRISM were years old at the time of Snowden gathering them, and even older at release... just imagine how much further things have progressed in the 10+ years since. (iirc lots of them had 2007 dates on them)

nojito• 6 years ago

Apple almost never bends over for advertisers. The closest they have done is pushing a privacy change launch date further down the line.

https://www.theverge.com/2020/9/3/21420176/apple-ios-14-trac...

https://www.telegraph.co.uk/technology/2020/12/08/advertiser...

MrStonedOne5• 6 years ago

The whole design of this DNS system would mean that even if apple ran a ODOH proxy, they still wouldn't be able to see what the request was for.

What data can apple give them?

landerwust6• 6 years ago

Opened this post expecting to be hating on another power grab dressed up as protocol engineering, but this one seems to actively /reduce/ the centralization of user data collection in DoH. Props to Cloudflare, I'm impressed.

syshum• 6 years ago

I still have doubts, 1.1.1.1 was a clear power grab and effort to control more of the internet. DoH in partnership with Mozilla was an extension of that

So I am still suspect of their motives but maybe the negative PR got to be too much

Avtomatk• 6 years ago

I would like someone to correct me if I am wrong, but I think we can never have 100% privacy because the destination IPs cannot be encrypted or hidden, so as long as the destination IP can be observed, the server that you are connecting at can be obtained (I know a server can host many web pages, but this requires the port, which cannot be encrypted either).

So I don't know to what extent this protocol can be useful.

sneak• 6 years ago

I'm more worried about persistent, authenticated/ID-linked TCP connections (e.g. APNS) providing the client IP over time to an application service provider (e.g. Apple, Slack, Google, Microsoft, et c), that is, city-level geolocation track history via geoip, than I am the ISP or carrier snooping on what websites I connect to.

Every iPhone connects to APNS for push notifications and stays connected, and, last I looked at the protocol, the client certificate was linked to the device serial number. That's quite a geoip tracklog dataset, and AFAIK you can't turn it off.

It's to the point now that to keep my city-level location private from Apple, I'm not putting SIMs in any of my iPhones/iPads any longer, and carrying a battery powered VPN travel router (with a SIM uplink in it) for them to talk to. Super annoying that it has to come to this.

landerwust6• 6 years ago

This is "fixed" in DoH the same way it's "fixed" for encrypted SNI: by having a small number of superproviders servicing millions of domains.

With current encrypted SNI proposal, your privacy (between you and the superprovider) is /improved/ by talking to a site behind a large aggregating provider. It sucks (since the superprovider still sees everything), but that's how it is.

edit: added clarifications in (parens)

fsflover• 6 years ago

but I think we can never have 100% privacy because the destination IPs cannot be encrypted or hidden

This problem is solved in I2P (https://geti2p.net) by adding a few intermediate hops between you and destination. You will know someone is connecting to the network, but you can't find what they're doing.

bennettnate5• 6 years ago

I think there's still pretty good worth in this protocol. DNS is one of the key areas where we voluntarily give away information on every single website we're connecting to to a third party. This protocol certainly helps that--as long as the proxy and recursive resolver do not collude, neither will be able to associate the websites you're looking up with your IP.

It does have its limitations; a MITM can still just as easily see which IP addresses you connect to and determine which websites are associated with those IPs. But ODoH isn't really meant to fix that. A VPN would be better suited to fix that particular privacy concern.

throwaway542353• 6 years ago

The only solution is onion routing AKA Tor and similar.

cesarb• 6 years ago

I know a server can host many web pages, but this requires the port, which cannot be encrypted either

You can host multiple web sites in the same port since the 1990s, using name-based virtual hosts (https://en.wikipedia.org/wiki/Virtual_hosting#Name-based). It's rare nowadays to use a port other than 80 (for http://) or 443 (for https://) for public web sites.

baskire2• 6 years ago

All I see is a proxy service and a way for cloudflare to get access to the data

wil421• 6 years ago

Do you want Google and your ISPs to see everything? Cloudflare and maybe Apple (not sure what infrastructure they’d have in this if any)? Another company like Cloudflare?

I don’t know the answer but I’m curious to hear everyone’s thoughts. Personally I’d like to prevent Google and my ISPs but Cloudflare could easily become Google in many ways.

diegocg2• 6 years ago

The proxy sees the client IP, but can't look at the encrypted DNS request.

The DNS server sees (deciphers) the DNS query, but not the client IP address.

It's a proxy, but with the sensible data encrypted with the server's public keys to hide it from the proxy. Cloudflare never knows who is sending the requests. How can they get access to the data?

ksec• 6 years ago

I am guessing most if not All future Apple devices / OS will default to use Apple Proxy for DNS?

eeZah7Ux3• 6 years ago

"""A key component of ODoH working properly is ensuring that the proxy and the DNS resolver never “collude,” in that the two are never controlled by the same entity, otherwise the “separation of knowledge is broken"""

Essentially this is no better than using an HTTP proxy or a VPN.

t0mas88• 6 years ago

A HTTP proxy (or VPN) know exactly who you connect to, even with SSL they know the target name since SNI isn't encrypted.

In this proposal the DNS-proxy doesn't know what you've sent to the DNS resolver.

TimWolla4• 6 years ago

So, having read the blog post from Cloudflare I don't understand why the proxy (needs to terminate|terminates) TLS.

I thought HTTPS proxying (or rather: Any TCP protocol) was a solved problem by the HTTP CONNECT verb or SOCKS proxies.

What am I missing?

landerwust6• 6 years ago

The user's IP address is masqueraded by the proxy, and neither the DNS mothership (Cloudflare) nor the ISP get to see both who the user is and what they requested. It's an extremely desirable property DoH currently lacks

TimWolla4• 6 years ago

Yes, I understand that. But I don't understand what ODoH does better than a run of the mill SOCKS proxy, such as Tor.

GoblinSlayer5• 6 years ago

Abuse. The message must be a DNS query, not arbitrary tor traffic.

ignoramous5• 6 years ago

Key bits from the Cloudflare blog https://blog.cloudflare.com/oblivious-dns/

The target [resolver] sees only the [DNS] query and the proxy’s IP address. The proxy has no visibility into the DNS messages, with no ability to identify, read, or modify either the query being sent by the client or the answer being returned by the target. Only the intended target [resolver] can read the content of the [DNS] query and produce a [DNS] response.
The whole process begins with clients that encrypt their query for the target using HPKE. Clients obtain the target’s public key via DNS, where it is bundled into a [SVCB/HTTPS] HTTPS resource record and protected by DNSSEC.
Clients transmit these encrypted queries to a proxy over an HTTPS connection. Upon receipt, the proxy forwards the query to the designated target. The target then decrypts the query, produces a response by sending the query to a recursive resolver such as 1.1.1.1, and then encrypts the response to the client. The encrypted query from the client contains encapsulated keying material from which targets derive the response encryption symmetric key.
...50% of the time ODoH queries are resolved in fewer than 228ms.

BTW, DNSCrypt supports "oblivious" encrypted DNS queries via what it calls Anonymized Relays https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Anonymized-D...

landerwust6• 6 years ago

DNSCrypt needs meaningful industry support otherwise it's sadly irrelevant. I think by now we can all agree "industry support" basically means the 3 browser vendors. DoH has at least Mozilla and Google on board, and presumably Microsoft are tailing along.

gsnedders• 6 years ago

DoH has at least Mozilla and Google on board, and presumably Microsoft are tailing along.

Note that DoH (and DoT) shipped in iOS 14 and Big Sur, though aren't particularly easy to enable.

GoblinSlayer5• 6 years ago

If they allow to configure DoH server, you can use https://github.com/DNSCrypt/dnscrypt-proxy

techelite3• 6 years ago

I urge people to stop repeating Apple Advertising. Claims of privacy and security are debunked weekly. You put yourself at risk if you believe it.

selykg• 6 years ago

Do you have actual proof of this or are you just going to make misleading claims yourself?

nalekberov2• 6 years ago

Privacy is a buzzword to boost sales even more. Perhaps the biggest problem with Apple is its nasty monopoly strategies, remember the times you could easily add more RAM, change batteries?

xondono• 6 years ago

Debunked where? If they were I’d expect HN to be the first to publish

MrStonedOne5• 6 years ago

Your statement is 100% correct but misses the entire point

https://nibblestew.blogspot.com/2020/04/your-statement-is-10...

londons_explore• 6 years ago

When you need a log-log plot to make the performance degradation not look so severe, you have issues...

3r8riacz• 6 years ago

145 ms response time when DNScrypt is around 10-25 ms, and anonimized DNScrypt is around 2-3x, wow

nalekberov2• 6 years ago

The more these big corporations involves in this process, the more we are gonna lose our privacy.

Centralization and too much power in certain amount of hands are the source of all evil.

jamescun• 6 years ago

Preventing the target resolver from seeing client's IP address breaks GeoDNS. This is already a problem with 1.1.1.1 which doesn't honour the EDNS client subnet extension.

Given generally DNS is just the start of an intereaction, usually followed by the connection directly between the client and intended destination, I don't see what kind of snooping these privacy measures are there to prevent.

ignoramous5• 6 years ago

Valid points, but...

Preventing the target resolver from seeing client's IP address breaks GeoDNS.

If the proxy and the target are in the same metro as the user, it shouldn't really matter.

This is already a problem with 1.1.1.1 which doesn't honour the EDNS client subnet extension.

1.1.1.1 runs at Cloudflare's edge. Most likely it is recursing DNS from more or less the same location as the user and so ECS isn't really required when in fact it exposes the client unnecessarily to upstream name-servers.

I don't see what kind of snooping these privacy measures are there to prevent.

The one where DNS resolvers build to sell browsing profile of its users?

snarf212• 6 years ago

Aren't these DNS resolvers largely the ISP anyway? They know where any packets are going anyway for each user. Seems to be a trivial hurdle to jump.

mike_d• 6 years ago

If the proxy and the target are in the same metro as the user, it shouldn't really matter.

Having ran one of the largest public DNS resolvers on the internet, I can tell you it is a big problem. GeoIP providers do not have the fine grained data to be able to tell that a resolvers unicast address is in Seattle vs Chicago for example.

Cloudflare doesn't care about edns-client-subnet because the only downside is that other CDNs appear slower to their users.

absolutelyrad• 6 years ago

As I see this, this is a very clever move by Cloudflare.

It's intentional to force websites to move to their CDN or atleast use a CDN with anycast and prevent you from making your own CDN like you could cheaply before (spinning up DO droplets and doing loadbalancing with geo DNS).

jgrahamc3• 6 years ago

That's a weird take. (a) this is a proposed standard not just some Cloudflare service and (b) you can just use Cloudflare DNS if you want and forget about the rest.

snarf212• 6 years ago

Encrypted DNS only solves hi-jacking, it doesn't provide privacy. DNS must be public. It is trivial to run a DNS server to build a simple reverse lookup table. This is as much privacy as the TSA provides airline security.

GoblinSlayer5• 6 years ago

The DNS server is centralized storage of all your browsing habits.

baskire2• 6 years ago

Thus increasing the cloudflare value-prop of anycast based load balancing.

jsmith45• 6 years ago

I don't see what kind of snooping these privacy measures are there to prevent.

The point of this is to prevent some cloudflare competitor offering DoH, but logging what dns names each client looks up, and selling that information, or using it internally.

Think about the ways that facebook would abuse that information if facebook ran a popular DoH resolver. For example, they detect that you have used a hookup app (based on dns lookups for their servers), and boom, now your facebook feed is full off condom adverts. Or thousands of other scenarios, some even more creepy than that.

fulafel• 6 years ago

GeoDNS was always a "works most of the time" hack relying on some widespread (but not universal) implementation details in routing and DNS infrastructure, no?

judge202010• 6 years ago

which doesn't honour the EDNS client subnet extension.

background: https://news.ycombinator.com/item?id=19828702

new23d2• 6 years ago

ODoH ensures that only the proxy knows the identity of the internet user and that the DNS resolver only knows the website being requested

Who is the proxy here, and who the DNS resolver?

MrStonedOne5• 6 years ago

This is a protocol, not a product. There is no set proxy, or resolver.

new23d2• 6 years ago

From the CloudFlare blog post:

A key component of ODoH is a proxy that is disjoint from the target resolver. Today, we’re launching ODoH with several leading proxy partners, including: PCCW, SURF, and Equinix.

theamk3• 6 years ago

This seems to require DNSSEC as a key function. @tptacek ?

tptacek3• 6 years ago

It has nothing to do with DNSSEC.

theamk3• 6 years ago

Huh? They say this:

The whole process begins with clients that encrypt their query for the target using HPKE. Clients obtain the target’s public key via DNS, where it is bundled into a HTTPS resource record and protected by DNSSEC. When the TTL for this key expires, clients request a new copy of the key as needed (just as they would for an A/AAAA record when that record’s TTL expires). The usage of a target’s DNSSEC-validated public key guarantees that only the intended target can decrypt the query and encrypt a response (answer).

So this looks like relies on DNSSEC as a core part of its security, and that any resolvers willing to participate in this protocol would have to set up one.

cblconfederate2• 6 years ago

Sullivan said a few partner organizations are already running proxies, allowing for early adopters to begin using the technology through Cloudflare’s existing 1.1.1.1 DNS resolver.

In other words, in order to thwart efforts to make the internet anonymous , US companies are planning to takeover DNS for the vast majority of people.

jgrahamc3• 6 years ago

Oh, please. ODoH is a proposed standard. Use whatever the hell proxy/resolver you feel like, wherever you like.

DNS is a shit show of unencrypted data flying around being scooped up by God-knows-who and along comes someone proposing a standard to fix said shit show and this is the response people get.

cblconfederate2• 6 years ago

Decentralized spying > centralized spying

corford• 6 years ago

Would have been a million times better if cloudflare had used it's considerable clout and resources to push/lobby for widescale DoT adoption rather than this fucking Frankenstein shit show that is DoH (now with even more garbage attached to it in the form of a proxy)

izacus• 6 years ago

So Google got sued by ISPs which lobbied an investigation by DOJ for trying to encrypt DNS: https://www.engadget.com/2019-09-29-congress-doj-scrutinze-g...

Will ISPs be too scared to sue Apple and Cloudflare for this? Or are they giving them an out?

floo• 6 years ago

If I understand this correctly this was mostly about Google getting an unfair advantage over the ISPs.

Which wouldn't be the case if everyone loses access to the IP + DNS request info.

MrStonedOne5• 6 years ago

So I do wonder how such systems can be designed or implemented such that geoip systems can still work.

While I'm sure aws route53 and cloudflare's own routing systems can handle this properly, Cloud isn't quite the answer. Not every workload fits on the cloud (see: Discord, which runs on leased servers), and a system that breaks down if your rented datacenters aren't in alignment with Cloud operating regions doesn't make a great solution.

notamy• 6 years ago

Not every workload fits on the cloud (see: Discord, which runs on leased servers)

As far as I'm aware (don't work there), only bandwidth/CPU-heavy stuff like voice and video live on rented dedis; the core chat services live in GCP.

dylz2• 6 years ago

Discord already doesn't need geoip, since they just direct you at wherever the server location (that you chose) is

teddyh• 6 years ago

Sounds promising. Get back to me when it’s gotten to the RFC stage. A ready-made solution thrown over the wall like this, is rarely what is ultimately adopted.

nuker• 6 years ago

Why not DoT? And DoH is mum on http cookies: "Determining whether or not a DoH implementation requires HTTP cookie support is particularly important because HTTP cookies are the primary state tracking mechanism in HTTP." https://tools.ietf.org/html/rfc8484

freebuju3• 6 years ago

Misleading title. Apple devices are not anywhere near ready to utilize this dns protocol. Apart from that, yeah let's shift our dns trust to one of the biggest data resolvers! The irony...

Encrypted dns might be already in use by government or military agencies, but they know too well the effects of cascading this tech down to the masses. They will never let this reach the public.

alwillis12• 6 years ago

Apple devices are not anywhere near ready to utilize this dns protocol.

The latest versions of macOS and iOS already support DoH and DoT; Apple could push an update tomorrow to enable ODoH tomorrow if they wanted to.

Encrypted dns might be already in use by government or military agencies, but they know too well the effects of cascading this tech down to the masses. They will never let this reach the public.

You do know we've had encrypted DNS for years, right? It has some issues, which this new protocol is designed to address. There's no reason to believe "they" can or will intervene to stop ODoH.

freebuju3• 6 years ago

I don't think you understand how DNS works.

DoT and DoH should not be confused for encrypted DNS.

Encrypted dns is still a myth to most users. Major resolvers do not support it since it directly conflicts with with their data collection business.

All forms of Internet communications can be largely encrypted. Dns is the last frontier remaining. It remains so for good reason...

darkwater3• 6 years ago

Until we get rid of SNI[1] in HTTPS for good there will still be providers (like my ISP) that do deep packet inspection on SNI and kill the connection right away if you happen to visit a forbidden site (and this was western Europe, yesterday, on a site behind CloudFlare)

[1] https://en.m.wikipedia.org/wiki/Server_Name_Indication

jgrahamc3• 6 years ago

About getting rid of SNI... https://blog.cloudflare.com/encrypted-client-hello/ Been working on that also.

darkwater3• 6 years ago

I wanted to link CF efforts on this also but somehow I forgot. Thanks for sharing and I really hope you are successful at this because what I experienced yesterday was really infuriating. Even if having everything behind a CDN to avoid ISP spying is still not the optimal solution, but at least is an improvement given what ISPs have already shown.

ignoramous5• 6 years ago

You can bypass SNI inspection [0] with tools like GreenTunnel [1] and Intra [2].

[0] https://twitter.com/vinifortuna/status/1304189371688660992

[1] https://news.ycombinator.com/item?id=22654737

[2] https://getintra.org/

d3nj4l• 6 years ago

I can't find any source on intra working to prevent SNI sniffing. The page itself only mentions DNS, and Googling doesn't reveal any other source for that.

E: NVM, found it. It does like it uses split hellos.

darkwater3• 6 years ago

Thanks for the link, just tried Green Tunnel on the use case where my ISP is blocking me and just managed to change the error from PT_CONNECT_RESET_ERROR to PR_END_OF_FILE_ERROR.

Side note, looks like that if installed by snap on Ubuntu 20.10 it cannot automagically change the proxy configuration in Gnome

  green-tunnel:system-proxy [SYSTEM PROXY] error on SetProxy   (Error: Command failed: gsettings set org.gnome.system.proxy mode manual
  green-tunnel:system-proxy /bin/sh: 1: gsettings: not found

Enabling proxy manually makes it work but yet, it doesn't circumvent my ISP filtering :(

judge202010• 6 years ago

Part of the counter-argument that has been so prevalent on HN (most recently: [0]) is that when you prevent middlemen on your network from being able to see what website you're browsing, you're doing exactly that: preventing anyone, even a trusted network administrator, from being able to inspect traffic. I'm all for DoH and ECH since US ISPs have a history of inspecting and logging traffic, but it seems like there should be a way to manage the devices on your network besides being forced to set up MDM on everything.

0: https://news.ycombinator.com/item?id=25314182

sroussey• 6 years ago

Yeah, but that argument sounds like asking people to use “logmein” as a password so they don’t need to install MDM on everything.

Management of devices without authentication and authorization means anyone can do it. Which is the state of things today (for DNS).

ReactiveJelly• 6 years ago

a way to manage the devices on your network besides being forced to set up MDM on everything.

It's sort of like cleaning malware off of an infected PC from within the infected OS.

It was always theoretically impossible, and now we're just seeing the gap of "Well in this case the enemy was imperfect" closing. It was never going to stay open in the first place.

mindslight• 6 years ago

it seems like there should be a way to manage the devices on your network

Administering devices with network settings is convenient, but rapidly vanishing because there's no technical difference between you administering your local network and a totalitarian ISP administering their users.

My ways of dealing with the modern world, in order of preference:

1. Use Free software, so that devices develop user-empowering features instead of being locked down.

2. Firewall all general Internet access from a device/VM, and let it talk to local network devices only.

3. Firewall the device/VM from accessing most of your network, allow Internet access (ideally through a VPN), and inspect the hardware to make sure there aren't microphones or cameras.

JoshTriplett7• 6 years ago

The vast majority of users do not have a "trusted network administrator"; they have a hostile upstream network. That's where the defaults come from. Trusting the network (or anything outside of the device itself) should always be a non-default setting, and nothing from the network should be able to change that setting. You should have the option of configuring a device you own and control to make its traffic inspectable, but that should never be the default.

throwaway542353• 6 years ago

No! Solving the SNI problem is far from enough.

The server IP address can be easily correlated with the domain for 90% of Internet traffic.

acdha8• 6 years ago

Do you have a citation for only 10% of internet traffic using CDNs? Even things like cloud load-balances and ephemeral IPs make those associations hard and we’re in third decade of major web properties using CDNs.

mmis10002• 6 years ago

The correct answer will be reverse, get rid of SNI completely and enforce ESNI everywhere.

Most bad entity now only need to block ESNI, and then the client will happily fallback to plain SNI.

If everyone enforce ESNI only, then it is not gonna going to work.

Just like nowadays, a browser can't view https site is completely useless because most of sites on internet were already encrypted(and the percentage is only going to be more) no matter how useful/useless the site is.

josephcsible2• 6 years ago

We don't need to kill regular SNI to fix that problem. If a site's DNS record indicates that it supports eSNI, and a connection with eSNI fails, then the browser should hard-fail. And middleboxes can't lie about whether a site supports eSNI, since that's protected by DNSSEC (and it should be coming over DoH anyway). This would break the bad actors without breaking every site that didn't upgrade to eSNI.

pcwrt3• 6 years ago

Use a VPN then.

clashmeifyoucan• 6 years ago

I'm wondering how they still get good performance with a proxy server in between, the plots seem quite close to each other (maybe because logarithmic?).

Also, not sure how useful the Tor comparison is, since Tor does 3 hops as opposed to their 1 so it would be a shame if it doesn't beat that.

jaimex2• 6 years ago

Whats the point?

Governments subpoena the information or just block the protocol outright. ( or in China, get it delivered to their door by Apple )

Commercial parties have a bag full of tricks from fingerprinting to embeds on the page itself to track you.

Privacy seeking users are already tunneling their traffic.

That leaves script kiddies at Internet cafes. TLS kind of fixed that already so... Good work?

MrStonedOne5• 6 years ago

As it stated in the article, ISPs tracking and selling the data.

Exactly that, no more, no less.

alecco• 6 years ago

You, the proxy, and the DNS service, can be in 3 different countries. It's not bullet proof but makes it quite hard for a single government. Unless you are a Bond villain I think this is more than you need.

If you need more than that use ToR or similar.

t0astbread• 6 years ago

While I agree that it's a step forward you should proxy your whole traffic anyways if you want to enjoy the benefits of encrypted DNS. Otherwise intermediaries routing your packets can still see what you connect to by looking at the IP header (or SNI, if not encrypted).

DoH/DoT is still useful because it allows you to proxy your DNS over Tor (for example) without having to worry about tampering (or surveillance if you also use separate circuits per domain).

crumbshot• 6 years ago

This is a neat design, but, does this not just shift the issue of trust as to whether the proxy and the target are colluding:

However, each of these guarantees relies on one fundamental property — that the proxy and the target servers do not collude. So long as there is no collusion, an attacker succeeds only if both the proxy and target are compromised.

I'm not sure how an end user would be expected to assess this any more than they could ascertain whether any particular DoH/DoT provider is as trustworthy as they claim.

wp381640• 6 years ago

Add a few more proxy hops and you’ve effectively reinvented Tor

eeZah7Ux3• 6 years ago

reinvented Tor, but with extra steps and less security

theamk3• 6 years ago

.. but the version of Tor which does not raise alarms on every corporate firewall/IDS system

diegocg2• 6 years ago

Well, this could probably encourage the creation of privacy-oriented proxys (they just have to forward queries, so it should be relatively inexpensive compared to a full DNS server). What is the likehood of someone getting logs from Cloudflare (who promises it does not keep logs, but let's assume it does) and at the same time hacks into some random privay-oriented organization?

Of course, one might imagine a State actor using all their resources to do just that. But this would be a very complex attack. At least, it would stop all kind of ad tracking.

The worst part of this proposal is that it will further centralize the DNS infrastructure.

dperfect• 6 years ago

Exactly what I was thinking. It doesn't even really help to run your own proxy on a server somewhere, because although the target wouldn't know for sure what the client's IP address is, queries from just one IP are likely to be easily correlated (statistically or otherwise).

So you convince some neighbors to use your proxy... As the number of clients grows, so does the uncertainty that the person running the proxy isn't colluding with the target, so you're back to the same trust issue that you were trying to solve in the first place.

thrwaway2020aug• 6 years ago

I'm surprised to see Cloudflare and Apple collaborating on privacy.

What does Cloudflare think of Safari's new CNAME-cloaking detection to block cookies? https://webkit.org/blog/11338/cname-cloaking-and-bounce-trac...

The reason I ask is because Cloudflare's "orange cloud" DNS mitigates that protection because it prevents Safari from detecting the cloak. On the other hand, I haven't run into many engineers who think CNAME-cloaking actually hurts privacy in light of Safari's other efforts to partition local storage.

Does Cloudflare think it would be help privacy for Apple to know the final IPs behind orange cloud DNS?

gwbas1c• 6 years ago

I suspect that practical matters will interfere with widespread adoption of encrypted DNS.

In my state, Comcast is going to start charging heavy bandwidth users extra. After a few people get surprise bills, I suspect that lawmakers will require that internet providers break down a bill by application.

joshspankit7• 6 years ago

After seeing similar things throughout the years, I feel like that is very doubtful. When tested, the push for privacy is much stronger than the push for cost.

api• 6 years ago

I’d just get Starlink. Even if the deal was worse in terms of cost it would be a way to say fuck you to the ISP. Without some way to do that ISPs will not be able to get away with such customer hostile behavior.

mschuster91• 6 years ago

Without some way to do that ISPs will not be able to get away with such customer hostile behavior.

I guess it won't take long until the first community or HOA decides to ban Starlink dish installations for faked "optical nuisance" issues.

selfhoster112• 6 years ago

Mobile OSes already support per-application network usage breakdowns. This is an OS-level feature, and not an ISP-level feature.

joshspankit7• 6 years ago

I understand why Cloudflare wants this (marketing, as well as being able to serve their customer’s content through restrictions, thus making them more valuable to those customers),

but why does Apple want this?

My knee-jerk is that they want to further hide/make unstoppable things like the Gatekeeper network checks, but there has to be more right?

PartiallyTyped2• 6 years ago

It is part of their marketing. The fact that others sell or actively use your data, e.g. google, facebook, microsoft, apple was handed the opportunity to charge a premium for the absence of such tracking and data usage. If you watch the presentations, they branded/poised themselves as the privacy centric approach.

joshspankit7• 6 years ago

I see your point about how they (will) position it, but I’m still curious about their actual motives.

simonh2• 6 years ago

Why would Apple care about hiding Gatekeeper traffic from internet providers?

joshspankit7• 6 years ago

I’m guessing they want to hide it more from users. The recent bypassing of local firewalls shows this, for example.

wlesieutre3• 6 years ago

Because it's none of Comcast's business what software I run?

ChrisRR• 6 years ago

2 reasons I can think of.

Firstly, Apple loves to act like they are always taking your privacy very seriously (of course that's not always true), so for the cost of a few engineers, they get a massive marketing point. "We take your privacy so seriously that we developed a new protocol to do so"

Secondly, Apple has an awful case of NIH syndrome. If they didn't develop it themselves, they would rather develop it from scratch themselves

alwillis12• 6 years ago

Secondly, Apple has an awful case of NIH syndrome. If they didn't develop it themselves, they would rather develop it from scratch themselves

Not when it comes to security and privacy. They knew DoH and DoT were good, but not good enough when it comes to privacy, which explains why they didn't just implement it like Google and Firefox did.

Instead, the worked with Cloudflare to standardize something that's better.

cannabis_sam• 6 years ago

Has Google produced any similar initiatives?

ksm1717• 6 years ago

Interesting that apple is increasing its stake in privacy. On all their billboards and advertisements of course they like to present it as a boon to the customer. More importantly, I think it’s a negative for personal data hungry competitors while being relatively unrelated to Apples business

atonse• 6 years ago

Yup I just see this as an alignment of interests. In this case, Apple's interest happens to align with that of their consumers.

And I for one am happy that they have taken up this cause and put their weight behind it, whatever their intentions may be, the effect is that it makes the web more private for those of us who deem it important to move away from the "monetizing data" cancer that has spread all over the internet.

John_Westra• 6 years ago

I would love to see Firefox be an early adopter of this, regain market share and save us all from Chrome!

akvadrako• 6 years ago

If anyone wants the draft RFC:

https://tools.ietf.org/html/draft-pauly-dprive-oblivious-doh...

throwaway542353• 6 years ago

REMINDER: Research proves that it's easy to correlate IP addresses in HTTP[S] connections with the domain you are connecting to with a very high success rate.

You can resolve the websites from the Alexa top 100k list and create a ipaddr -> website map that will successfully apply to 90% of Internet traffic without ambiguity.

A lot of research papers also show how easy it is to fingerprint and detect a TLS handshake.

Assuming the SNI problem is going to be solved, the other problems are still here.

TL;DR: use Tor.

mlegner• 6 years ago

The basic idea makes sense to me and it's great to see efforts to improve DNS privacy. However, I'm not really convinced by Cloudflare's analysis of the processing overhead:

The blog post only discusses how the proxying and encryption affect latency but not the processing at the server. In contrast to plain DoH (or DoT), where only symmetric cryptography is used after the first set-up, ODoH requires asymmetric cryptography (which is several orders of magnitude slower) for each individual request. The "less than 1ms" that they claim for the 99th percentile is no problem for the client but it is a problem for the resolver. Asymmetric cryptography is also used for verifying DNSSEC responses, but this is only necessary for records that are not cached.

On the other hand, an ODoH resolver may require to set up and keep track of a lower number of TLS connections as the number of proxies is likely smaller than the number of clients.

TrueDuality7• 6 years ago

The biggest and most consistent downside I see with these DNS enhancements is that it prevents filtering at the network level. Querying nameservers is being pushed into applications themselves to support these new features (such as Chrome and Firefox), which bypasses any system resolvers configured on the host. In most cases there is no way to signal from the network that it is not desirable to do this (Firefox being the sole exception). There also is no good way for enterprises to centrally manage these settings. DNS is a major source of information when doing threat hunting on a network and having that go dark is a big problem.

Enterprises aside, there has been a rise of people using solutions like pi-hole in their home networks to filter out traffic not just for ads, but known malicious domains, and telemetry trackers (which Apple does get filtered by, only calling them out specifically because they have an active interest in not being filtered like this).

Yes I think it's also a problem that ISPs are snooping and selling this information, but I think that is a less severe problem than rampant malware infections and the excessive collection of online usage data in the telemetry systems present in every webapp, OS, mobile, or IoT device. This increases privacy in one place, while making it much harder to actively protect yourself from the more aggressive and invasive sources of data collection.

hkt5• 6 years ago

Applications still have fallback though, right?

If so, I foresee blocks on DoH/etc to common resolvers like 8.8.8.8 and 1.1.1.1. I'll be blocking them at home on the assumption that I only want regular DNS lookups so I can point them to my own DNS server etc.

0x4265776172652• 6 years ago

Blocking traffic for known DoH services would be trivial. How about blocking unknown, how would you block that?

TrueDuality7• 6 years ago

Firefox and Chrome do yes, but none of these standards specify any kind of fall-back behaviour. There are no guarantees that any specific device or application needs to do that or how.

There is a cost to firewall rules like that as well. Who is going to maintain a list of all the IPs on the internet that are hosting DoH servers that could be used? What about the potentially more prolific proxies specified in this protocol enhancement? How does a network administrator keep all of those in sync with their edge networks? How does a home user?

Since DoH uses HTTPS there is no reason a service can't be multihomed on the same IP just like SNI allows multiple HTTPS servers on one IP. Would you be willing to block a legitimate website just so the applications on your network might fall-back to the name server you want them too?

salgernon• 6 years ago

Trying to do content filtering on the kids chrome books for remote learning, I installed a pi-hole and was generally pleased with it. Then the kids (8 & 12) figured out to change the dns to cloudflare or google directly. I ended up having to add static routes on the router to block those paths.

(I need to block distraction sites during instruction time - otherwise it’s endless Minecraft videos while in zoom meetings...)

specto• 6 years ago

I have blocked 1.1.1.1 and 8.8.8.8 and noticed some devices behave very badly, often crashing or restarting. Debugging the issue, once I removed the firewall rule they behaved normally. Almost all of the affected devices were google related, Android TV for example.

rsync3• 6 years ago

"If so, I foresee blocks on DoH/etc to common resolvers like 8.8.8.8 and 1.1.1.1. I'll be blocking them at home on the assumption that I only want regular DNS lookups so I can point them to my own DNS server etc."

I wish it were that easy but it's very predictable that google will start resolving DoH on plain old "google.com".

So will everyone else ... it's not going to be malicious.userhostile.resolver.samsung.com, it's just going to be samsung.com ... so you can block it but you'll be blocking more than just the resolver ...

yegle• 6 years ago

Enterprise can disable DoH in Chrome using a group policy.

TrueDuality7• 6 years ago

You're right, that doesn't help with Apple devices though which has seen a huge market share increase with day to day users in the businesses that I interact with. Same thing goes for mobile devices, even those with enterprise management systems attached.

The options are simply not there for consistent management of your network.

vinay_ys• 6 years ago

Enterprises can also disable direct outbound connections to anywhere. They can insist only way to access anything is via http proxies. You can do the same at home with a pi-hole. On iOS/MacOS you can install content/network filters. If a browser or app breaks these basic functionalities of Internet, then good luck to them.

crispyporkbites2• 6 years ago

why should DNS be handled at the system layer and not by applications? There's zero controls in place to stop this so I don't see why it's assumed that every application developer will want to use system defaults and not override it.

gumby2• 6 years ago

I don't see why it's assumed that every application developer will want to use system defaults

It's the user's machine not the application developer's.

j16sdiz• 6 years ago

Because, DNS, like default gateway and ip address, are configured by DHCP? Zoned DNS server for intranet is very common.

gumby2• 6 years ago

Querying nameservers is being pushed into applications themselves...

I agree: this absurd trend will lead to every app essentially including an entire O/S. There are several reason why OSes provide services to applications and one is that the OS manages the user's configuration (e.g. what devices are plugged in, where and how to resolve names, cacheing data, etc).

I also find it rather insane the amount of overhead required to resolve a name when an entire http connection needs to be set up and torn down for the process.

rusk• 6 years ago

I presume there’s some kind of connection pooling going on ... but yeah you’ve still got the needless verbosity of HTTP for a specialised high volume protocol ...

stevepike2• 6 years ago

As someone who recently set up a pihole, I was shocked that it was possible to redirect all DNS requests on the network (in plain text!) to the pi. I did the method where you set up a network firewall at the router level that redirects all port 53 traffic to the pi. It's a nice feature for getting my xbox filtered, but it really felt like an insecure historical quirk rather than a feature we should be praising.

Surely it's progress for devices to be able to securely access name servers? I can't snoop on the network traffic going over https but somehow I can get a list of all names queried?

TrueDuality7• 6 years ago

You're definitely right that it is an issue that the traffic is plaintext but there are trade off costs that are not addressed by these standards, mostly in user control and fall back behaviour.

You've started using a pi-hole, and presumably are getting value from it. These protocols can potentially make it so you can't use that pi-hole at all.

Traffic that is local to a network being unencrypted is not a huge privacy problem. If this protocol was adopted by local resolvers, your pi-hole or network router could use it for any requests it makes while still preserving its ability to filter the traffic. It's basically all win under this scenario.

The problem comes back to applications implementing this in ways that can't be managed taking the option away from end users and administrators. Without the protocols specifying control and fall-back behaviours on networks that don't need or want this, it's more harmful than useful.

OJFord5• 6 years ago

The 'historical quirk' per my understanding is pretty much IPv4 NAT.

At least, I couldn't figure out how to do it with IPv6 (no (need for) NAT) - I ended up dropping them if not destined for my desired DNS instead.

(NAT lets you Translate Addresses, usually to save IPv4 space, but here to redirect to a different DNS. IPv6 fixes the address space problem with more addresses, so the hack is done away with, and everything on the network can 'route itself' to everything else without any translation, as pre-NAT and as always intended.)

iso9475• 6 years ago

It’s progress if you control your devices, or you don’t control your network.

I don’t. Like most people I can control my network.

I have all sorts of crap on my network from Bose and amazon and Nintendo and Apple etc on my IoT vlan.

Without going to a monk style digital life aka RMS, the best bet is to segment them into a secure network and limit what they can communicate with. The DOH Culture and the like takes away my freedoms.

1vuio0pswjnm74• 6 years ago

"I can't snoop on the network traffic going over https but somehow I can get a list of all names queried."

SSL/TLS's servername extension puts those names in plaintext just like DNS. The popular browsers all include this extension even when the website does not require it.

As such, one can get a list of names by snooping on HTTPS traffic, instead of DNS traffic:

https://github.com/kontaxis/snidump

ESNI-enabled software and Clouflare's ESNI-enabled CDN is an option, but you have to keep making DNS queries to get a key that changes every hour.

xg158• 6 years ago

If I get access to those devices, yeah, sure. But in practice, I'd argue this actually reduces privacy for users, as it gives apps and devices a secure path through the network which cannot be monitored by any intermediary - including the user of the app or the owner of the device themselves. So no chance to find out what kind of data is being transmitted there either.

To me, DoH seems less about protecting the user from attackers and more about protecting apps and devices from the user.

m463• 6 years ago

The answer is - it depends.

If you own the device(s) (your internet connection, phone or a colo), and it is someone else's network - you want security.

If it's a device (smart tv, media player, iot) that you don't "own" on your network you want control.

vim1234• 6 years ago

Yeah it is true, but the problem is if DoH with its privacy features come along it will be literally impossible to block ads with PiHole, as all DNS quesries will be encrypted (which DoH does ofc rihgt now).

So no ability to block ads in TV or malicious domains that IoT deviced connect to or even blocking Windows, macOS telemetry network wide as all DNS requests will be encrypted which they are not as of right now.

acdha8• 6 years ago

The problem is that the things you most want to block can trivially bypass your local DNS filtering - DoH is just standardizing something which has been done for decades.

The only effective measure is to block outbound network access and require use of a proxy, possibly optimized by allowing direct traffic only from clients with functioning endpoint monitoring agents.

fiddlerwoaroof7• 6 years ago

How can they trivially bypass this local filtering? If the router is redirecting all port 53 traffic, there is no way to bypass aside from some alternate name resolution scheme.

yardstick3• 6 years ago

DoH is highlighting the security nightmare that is AWS, GCP, Azure, Cloudflare etc with their reverse proxies and virtual hosts, making it impossible to safely restrict a network from communicating with only a specific cloud-hosted service.

Also often perfect security isn’t required. Doors with locks are good, but useless if the burglar just breaks the full length glass window next to it. They still serve a purpose, but don’t need to be an absolute comprehensive solution.

JMTQp8lwXL2• 6 years ago

Can't you do something analogous to editing your hosts file (but for name servers) and then re-centralize all of your apps using a single name server, which you can then control however you like?

iso9475• 6 years ago

No, because instead of setting your network to give out your DNs server to all of your devices, it’s ignored by the apps

Instead of setting your devices to use a dns server of your choice it’s ignored by the apps

Some apps allow you to configure them, so now you’re configuring 200 apps on 20 devices rather than just one dhcp setting.

(Oh and OSs have generally broken hosts files)

rubyfan2• 6 years ago

When enterprises own the devices on their networks they can add whatever root certificate they like and MITM filter whatever they like. This makes over the network traffic more secure and does nothing to really impact threat detection.

If you don’t own the device then 1) should you be interfering or snooping the traffic at all? 2) if you need to limit threat then subnet clients you don’t own.

TrueDuality7• 6 years ago

Adding in root certificates and performing HTTPS MITM even on your own network is a huge risk on its own. You're basically breaking many layers of security such as certificate pinning that just get disabled with any custom root certificate. Those middleboxes will always break client certificate authentication and you're trusting that they are checking the various revocation lists they should be (CRL/OSCP/various built-in blocklists).

For your basic premise to work, it also means that the MITM middleboxes will need to support the DoH protocols and support recording, and filtering those responses.

Additionally, custom roots certificates will only work on devices that you can actually set a custom root certificate for, a great example is IoT devices. Is your TV suddenly talking to a botnet or was that a legitimate update?

We can argue about whether those middleboxes are even sane to deploy (hint: they're not), but what is historically true is that they are known to update slowly to new protocols, if at all and are known to cause compatibility issues for traffic that is inherently expected to be unchanged. They're enough of a problem at the _TCP_ layer that QUIC was explicitly designed that minimal information is available in the protocol headers so middleboxes would have less to mess with.

topranks2• 6 years ago

Not with TLS1.3 and DoH and ENSI they can’t.

zem• 6 years ago

do you own a smart tv in your house?

admax88q2• 6 years ago

Pi-hole is still very much niche, and outside of that and enterprise network admins, the majority of users are stuck using the trash resolver of their operating system directed to the trash DNS servers of their ISP.

If DNS level blocking ever becomes popular enough, malware authors will change their systems to not use the system's DNS, or to use hard coded DNS over TLS/HTTP servers that they know will serve them the data they want.

Preventing proprietary applications from doing malicious things is a constant cat and mouse game. Pi-hole works well for now, I would argue, because it's not popular enough to put a big enough dent in the success rate of malware.

TrueDuality7• 6 years ago

pi-hole is the most recognized name on here, but I think you're wrong about DNS level blocking. There are lot of home routers that have started integrating that feature natively. A few examples that I know off hand:

- Motorola MH7022

- Eero

- Disney Circle

Basically any of them that say "content filtering" in their product sheet are using DNS level filtering.

...the trash resolver of their operating system...

I'm very curious why you think the well tested, vetted, and constantly updated resolvers built into OS's are "trash". Is it just because most don't have support for DoH or DoT?

zamadatix• 6 years ago

DNS level blocking is extraordinarily common in enterprise settings though so the cat and mouse game for malware trying to avoid it is decades in the making at this point, pi-hole is just a recent common name in the prosumer space.

wtetzner• 6 years ago

I don't know much about the tech, but would it be possible to setup your own local DNS server that your machines point to, and do the filtering within that DNS server?

zachm0• 6 years ago

Yep! If you have a Raspberry Pi, look into Pihole. Some routers have this capability too.

rsync3• 6 years ago

I run my own recursive resolver (DNS server) in a datacenter.

This DNS server gets its upstream resolution from nextdns.io which is configured with several blocklists - including one that is roughly analogous to ublock origin.

On my local network, my DHCP server hands out my DNS server to all clients.

This means that all clients on my network get fairly robust ad-blocking even if they do not have an adblocker installed. It also means that non-browser clients (Sonos, AppleTV, etc.) get ad/tracker blocking as well.

DoH sort of breaks all of this, unfortunately.

Individual devices or clients or browsers can now connect to trackers and ad-servers over HTTPS, bypassing my adblocking resolver.

I thought that perhaps there was a solution wherein you would pre-query every single new IP you connected to over HTTPS and send it a test DNS query .. and if it answered DNS, you would just refuse to talk to it. I think this falls apart, however, if (for instance) google just queries "google.com" ... now you're denying google.com because it answers DNS queries over HTTPS...

Look, back when 8.8.8.8 came online I could just smell it ... I knew there was a user-hostile arms race somewhere in there I just didn't know where. Now we know.

1vuio0pswjnm74• 6 years ago

It is not difficult to run own DOH server. For example, dnsdist >1.4 seems to be a popular choice:

https://blog.apnic.net/2020/02/28/how-to-deploy-dot-and-doh-...

saurik3• 6 years ago

On every single operating system it is possible for this kind of improvement to be installed as a system-wide replacement for the local resolver, whether by a direct plugin or by running a resolver on localhost. This is how these upgrades can be deployed if you don't want to wait for the OS.

The problem is that browsers and other applications are just unwilling to let the user see how their products work or decide anything for themselves--or even just architect their installers to involve dependencies on a shared resolver upgrade--and so we end up in this hell of applications actively hiding their traffic from you.

And like, "great": now we have a new version of DoH and have to wait for everyone to upgrade their apps that upgraded to DoH before? This is ridiculous bullshit... this should be a single app on your device you now upgrade. Hell: Cloudflare even develops that app for a number of platforms! They aren't even the problem... it is everyone who jumps on "embedding" this behavior :/ :/ :/.

(For a more technically-comprehensive rant about this, read my comment from a year ago:)

https://news.ycombinator.com/item?id=21701808

judge202010• 6 years ago

iOS and MacOS technically have this (requires a profile[0]) but Microsoft will probably drag their feed on this for the next 2 years with the amount of enterprise customers they have to keep happy; and, given that the network adapter config is still based on Aero controls, they're probably in no rush to add more configuration options before upgrading it to Metro controls.

0: https://paulmillr.com/posts/encrypted-dns/

notwedtm• 6 years ago

Giving the user the ability to expose these requests by sending an HMAC of the domain to a local resolver could help with the privacy portion, but still allow for custom routing based on context.

dhaavi4• 6 years ago

bypasses any system resolvers configured on the host

With the Portmaster (https://github.com/safing/portmaster) we actually tackle this problem by notifying software (eg. Firefox) or blocking their connections, forcing them back to plain DNS, which we can redirect and handle. Take a look!

josephcsible2• 6 years ago

It's a good thing that network-level filtering is getting harder. If you can use network-level filtering to block ads/trackers/malware from your own devices, countries and ISPs can use network-level filtering to censor other people's devices. If you want to protect your own devices, do it locally, even if it means configuring Firefox instead of just the OS.

karmakaze2• 6 years ago

In a nutshell: client encrypts to proxy, which decrypts & removes client info, then asks resolver.

“What ODoH is meant to do is separate the information about who is making the query and what the query is,” said Nick Sullivan, Cloudflare’s head of research.
In other words, ODoH ensures that only the proxy knows the identity of the internet user and that the DNS resolver only knows the website being requested. Sullivan said that page loading times on ODoH are “practically indistinguishable” from DoH and shouldn’t cause any significant changes to browsing speed.

nathcd• 6 years ago

client encrypts to proxy, which decrypts & removes client info

This is incorrect; the proxy doesn't decrypt. It just proxies. From https://blog.cloudflare.com/oblivious-dns/ :

The target decrypts queries encrypted by the client, via a proxy. Similarly, the target encrypts responses and returns them to the proxy. [...] The proxy does as a proxy is supposed to do, in that it forwards messages between client and target.

karmakaze2• 6 years ago

Thanks for the clarification. So client encrypts for the resolver and sends an opaque payload to the proxy.

g42gregory2• 6 years ago

Do I understand this correctly that if DoH is implemented, none of the firewalls will be able to block the web sites? Including the pi-hole firewalls, as an example. If that's the case, this situation can't stand for long. Does this meant that the DoH would need to be extended to allow firewalls to decrypt it?

If not, here is a PaloAlto Networks blog advertising capability to block all DoH traffic, presumably at work [0]. It looks like you might not be able to use DoH at work, the way it currently stands. I wonder what would be the right solution?

[0] https://live.paloaltonetworks.com/t5/blogs/protecting-organi...

DoctorOW• 6 years ago

What's stopping your PiHole from just getting its own HTTPS cert?

g42gregory2• 6 years ago

I am still a noob to the networking. I just started using OpenWrt router to manage my home network. OpenWrt has an option to enable DNS over HTTPS. Is this all one would need to do in order for the firewall rules still work with the DoH browsers?

1over1373• 6 years ago

Do I understand this correctly that if...

You understand correctly. DoH mostly defeats pihole and the like. Presumably Google and other ad companies love this.

jeroenhd• 6 years ago

DoH isn't blocking anything that any existing application can already bypass. It merely points out the fact that the rise in encryption makes it difficult for third parties to administer the software running your device.

DoH will not be extended to allow firewalls to decrypt it. The entire point of DoH is that firewalls cannot do that. It's not hard for an administrator to set up their own DoH server, though, so there is no need as long as that server can be configured at the network level. This is currently possible through group policies on Windows and most MDM applications on mobile devices.

The nice thing about encryption is that only the software and the server know what is being exchanged. The not-so-nice thing about encryption is that only the software and the server know what is being exchanged.

You already can't see the difference between your computer connecting to some S3 bucket to download a picture of a cat or malware connecting to a S3 bucket to get a list of IP addresses mapped to host names. It's possible to run fully-fledged VPNs that look exactly like normal HTTPS traffic on the network level. DoH changes nothing about that.

On enterprise networks, IT administrators can already put measures into place that prevent DoH on support applications and restrict HTTPS connections to trusted hosts (through SNI sniffing + validating the connection). The upcoming encrypted SNI will make this harder, but group policy will be able to disable eSNI on any trusted computers and browsers, leading only untrusted software to be unverifiable, which can then be reasonably classified as malicious.

If IT administrators cannot put measures on employees' devices then... well, they've already lost. Before DoH, they just didn't know that they'd lost yet.

Palo Alto currently blocks DoH by decrypting all TLS traffic (ranging from cookie recipes to naked pictures your phone is syncing to the cloud) with a man-in-the-middle attack which requires their certificate authority to be installed on your system. They filter out the DNS requests inside those TLS streams and apply some kind of rule to them. Right now, they can either block the requests or change the contents (as long as the website and/or client doesn't use DNSSEC).

With ODoH, changing the contents will no longer be practical, but blocking the connection will be. Together with decent group policy settings, networks with such a setup should be as safe as they were without ODoH.

On a side note: these types of middleboxes are often trying to be transparent and silently violate many standards, breaking stuff that works on every normal network. Stuff like these firewalls are the reason that TLS 1.3 is pretending to be a special type of TLS 1.2 every time it connects, because otherwise some big middlebox vendors' platforms freak out and kill the connection. I doubt the inevitable transition towards HTTP/3 or even HTTP/4 will do these boxes much good. I don't put a lot of faith in devices like this.

CyberRabbi• 6 years ago

All security theatre while SNI is still universally deployed. Even then most IP blocks are static and easily correlated to source site.

A tor-like solution is the only real solution for this threat model

eh78ssxv2f• 6 years ago

What a stark difference between Google and Apple/Cloudflare.

Apple/Cloudflare are working on privacy-friendly protocols that reduce the amount of information exposed to them.

At exactly the same time, Google is working on proxying browser traffic through them without any consents [1].

[1] https://news.ycombinator.com/item?id=25337995

PikachuEXE• 6 years ago

I guess all the user "consent" for Google proxying (spying) users are included in the ocean of ToC text

Thus I am using Google Chrome only for Web Dev

benlivengood• 6 years ago

Metadata privacy is very hard to solve and traffic analysis of non-Tor traffic is pretty accurate, which is also applicable to CDN traffic regardless of how well DNS is protected.

http://ceur-ws.org/Vol-1158/paper2.pdf

ajnin• 6 years ago

At what point should we just throw out IP out of the window and figure out something new ? OK maybe not IP since all hardware infrastructure is based on it, but the whole idea of associating services to publicly open ports on the target machine. I'm thinking connections should be encrypted at the operating system level and then services would plug in at some higher level in a way that cannot be detected by outside observers.

zero_deg_kevin• 6 years ago

No hubris here at all.

But seriously, fuck this protocol and fuck every other BigCorp-sponsored protocol to remake the Internet. We the People Who Implement Protocols are too busy keeping the lights on to chase incremental, nice-to-have improvements.

judge202010• 6 years ago

Would you believe that HTTP/1.1 was made by people from Microsoft, Xerox, and Compaq with the sole purpose of being a nice-to-have improvement over an existing widely-used protocol, HTTP/1.0?

https://tools.ietf.org/html/rfc2616

phlhar• 6 years ago

The title of the article is really misleading. I though of a succesor to IPv6 and not DNS. It shouldn't say "internet protocol", thats technically not correct

Lammy4• 6 years ago

It bothers me how "privacy" has been redefined in recent years to mean "encrypted" and not "surveillance-resistant". We keep building things that make more requests I can't terminate locally, e.g. to a PiHole.

Never forget the lesson in "Using Metadata to find Paul Revere": https://kieranhealy.org/blog/archives/2013/06/09/using-metad...

Kalium6• 6 years ago

As another HN user put it: https://news.ycombinator.com/item?id=25349426

Administering devices with network settings is convenient, but rapidly vanishing because there's no technical difference between you administering your local network and a totalitarian ISP administering their users.

Your ability to terminate things locally means that finding Paul Revere with metadata isn't needed. It's a lot of work when you can just directly look at all your country's traffic.

hkt5• 6 years ago

People in totalitarian regimes aren't safe. This is kind of a given.

What everyone everywhere can resist, though, is corporate surveillance. That's the aim people should have.

xg158• 6 years ago

Until the country where all those network connections terminate turns totalitarian...

SamuelAdams• 6 years ago

I've not read that analysis before, thanks for the great read!

jlgaddis2• 6 years ago

Even better, IMO, would be if all targets were also proxies and a client could choose -- at "query time" -- any combination of (proxy, target) that they prefer.

If you wanted to go a step further, you can even allow "chaining" of proxies, such that the path a query takes might be, in an extreme example, similar to how Tor operates:

  Client -> Proxy 1 -> Proxy 2 -> Proxy 3 -> Target -> Resolver

Anyways, this is kinda sorta interesting, I guess, but honestly I'm more excited by and looking forward to the (hopefully!) eventual adoption and roll-out of "DNS SVCB and HTTPS RRs" [0] -- one of the other I-Ds (linked in the OP) on which ODoH is built -- and I suspect many other HN'ers will be as well (although I'd happily settle for SRV RR support in browsers).

[0] https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-02

vanshg• 6 years ago

Sounds like Tor/Onion Routing?

dang2• 6 years ago

All: We changed the URL from https://techcrunch.com/2020/12/08/cloudflare-and-apple-desig... to the more detailed source, but you might want to read both.

OJFord5• 6 years ago

What's the advantage of this over specifying a DoH provider (as we do today with plain DNS)?

Unfortunately I suppose the only way to really do that is with a resolv file (adlist/blocklist) of DoH hosts (which exist) but instead of pointing to 0.0.0.0, point to <preferred DoH>.

Edit - d'oh! I see it now - that would mean DoH provider knows query and IP, whereas here the ODoH proxy knows your IP but not the query. Nice.

dj_mc_merlin• 6 years ago

Is it not still possible to do a pi-hole kind of setup for DoH or ODoH? All you have to do is setup the server as a proxy for all http(s) connections on top of DNS connections and trust its cert on the client. If we can reliably block all ad networks with uBlock origin, picking out DNS requests from other http requests should be even simpler, right?

aftbit• 6 years ago

Can the proxies be (ab)used to proxy arbitrary HTTPS traffic?

hkt5• 6 years ago

DNS privacy for DoH effectively means we all lose the ability to control what our devices are connecting to. In particular, we can't block ads and trackers at the network level. The lack of fallback to regular DNS in the spec means we will choose between devices that track us while they work, or devices that are broken.

elliottinvent• 6 years ago

Cloudflare is committed to end-user privacy.

Pretty crucial hyphen

exabrial• 6 years ago

Hilariously I see privacy invading advertisers loving this. No more DNS blocking ad traffic! And since it's only a matter of time before Apple removes root access on their PCs, it puts them in complete control off what you see.

geogriffin2• 6 years ago

Why encrypt the first hop? Why isn't this just plain DoH with a simple CONNECT forward proxy to 1.1.1.1, like Signal's Giphy proxy [1]?

[1] https://signal.org/blog/signal-and-giphy-update/

pcwrt3• 6 years ago

Totally agree. Just posted my own question here: https://www.pcwrt.com/2020/12/oblivious-dns-over-https-vs-do...

geogriffin2• 6 years ago

Answering my own question.. A cryptographer friend offered an answer to this question: The network operator may be the same as or colluding with the target resolver, defeating the anonymization of the proxy.

Once we say we need encryption on the first hop, then I can see the logic in using a stateless protocol instead of TLS for the second hop, to avoid TLS-in-TLS and all the round trips associated with that.

Side note: It'd be cool if these new protocols used the more generic Noise Protocol Framework [1] instead of a custom, more specialized protocol they just came up with like HPKE [2].

[1] http://noiseprotocol.org/noise.html [2] https://www.ietf.org/id/draft-irtf-cfrg-hpke-06.txt

ittan• 6 years ago

This should be called DOHW, DNS over http made worse.

dylz2• 6 years ago

Are ODOH resolvers by any disjoint partner available yet? The only one I see is the CF-owned and run one.

tie_• 6 years ago

No discussion of DNS privacy should go without a link to Bert Hubert's awesome talk on the subject: https://www.youtube.com/watch?v=pjin3nv8jAo

anonypla• 6 years ago

One should also note that, even if you use ODoH, eSNI and even Tor (or any VPN service), your ISP could still reliably fingerprint your web access activity at the source using deep learning with over 96% accuracy as shown in this study (https://distrinet.cs.kuleuven.be/software/tor-wf-dl/).

So while ODoH is a good thing (and also recommended in this study which has shown the weaknesses of DoH/DoT https://www.esat.kuleuven.be/cosic/publications/article-3153...) and is very similar to DNS over Tor with a DNS hidden service resolver (which Cloudflare also provides). It won't prevent a skilled and motivated adversary from determining your activity and possibly apply censorship.

I would guess that a solution to mitigate these would be to use an hybrid solution of VPN over Tor (or Tor over VPN) while also using DNS over Tor or ODoH and eSNI.

pcwrt3• 6 years ago

Serious question, why do we need ODoH at all? Isn't a plain proxy good enough to achieve this? https://www.pcwrt.com/2020/12/oblivious-dns-over-https-vs-do...

Improving DNS Privacy with Oblivious DoH

Related Stories