Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Improving DNS Privacy with Oblivious DoH

blog.cloudflare.com

Post reply on HN
Print view View original

301–310 of 367 posts

Re: Improving DNS Privacy with Oblivious DoH

#301

Post by judge2020 »

freebuju wrote: post #265
alwillis wrote: post #249

Earlier quoted context omitted.

I don't think you understand how DNS works. I don't think you're in a position to comment on what I do or don't know about 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. Except those users using Firefox or Chrome, which come with DNS over HTTPS (DoH) preconfigured. Or those who've been running DoT on their home…

Again you keep referring to DoT and DoH which I insist do not encrypt your dns queries from your ISP. They may offer added security but do not keep your requests private. ODoH attempts to keep your requests private from the resolver only. A benefit which is a good step but doesn't ultimately keep your dns private from your ISP. This is the major flaw I find with such claims of encrypted dns. Your isp can still see wh…

So if your DNS request is encrypted to the resolver, and from the resolver to a second resolver (first resolver is ODOH proxy), then is unencrypted from that resolver to the authoritative nameserver, where does the ISP get to see your DNS query? Unless you mean SNI, which is its own thing being worked on[0] (yes, it only works for big CDNs to look benign and you probably could still correlate IPs via traffic patterns. Doesn't mean it'll be as easy as it is now, though).

0: https://blog.cloudflare.com/encrypted-client-hello/

Re: Improving DNS Privacy with Oblivious DoH

#302

Post by judge2020 »

zero_deg_kevin wrote: post #185

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.

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

Re: Improving DNS Privacy with Oblivious DoH

#303

Post by judge2020 »

teddyfrozevelt wrote: post #283
judge2020 wrote: post #211

Earlier quoted context omitted.

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/

It's almost ready in Windows. https://techcommunity.microsoft.com/t5/networking-blog/windo...

nice to see - looks like it's even been ported over to the settings app -

https://blogs.windows.com/windows-insider/2020/08/05/announc...

I still think Chrome and FF having it is a net positive though - The steam hardware survey shows 7% of users' OS is a Windows version before 10, so all of these users can use it today before it gets to them in the next major Windows 10 update.

Re: Improving DNS Privacy with Oblivious DoH

#304

Post by Kalium »

Lammy wrote: post #298
xg15 wrote: post #270

Earlier quoted context omitted.

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

Or until your country makes some friends and they decide to share their piece with each other until they recover your whole request.

There is no system that both allows communication between multiple parties and is infinitely resilient to a sufficiently determined, large, and well-funded group of people with guns.

What we can do with design and architecture is make each breach of communications security consume greater resources than unencrypted DNS, unencrypted HTTP, and unencrypted email.

Re: Improving DNS Privacy with Oblivious DoH

#305

Post by vim1234 »

stevepike wrote: post #145
TrueDuality wrote: post #119

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…

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

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.

Re: Improving DNS Privacy with Oblivious DoH

#306

Post by jiggawatts »

yardstick wrote: post #243
acdha wrote: post #151

Earlier quoted context omitted.

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.

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,…

The biggest mistake I see in public cloud fundamental architecture is that it uses IPv4 end-to-end, instead of just as a compatibility add-on to native IPv6 networking.

Literally all of the security issues caused by the public cloud network architecture instantly evaporate with IPv6, as well as much of the configuration complexity.

No more private networks with non-routable addresses! Instead you get a public-routable IPv6 block.

No more split-routing issues.

No more "gateways" or "peerings" or "service endpoints".

No more Private DNS Zones that may or may not work across virtual network boundaries.

No more copying DNS records into on-premises Active Directory DNS.

Every VM can get a globally unique address. So can every service, of any type! No more conflicts. No need to carefully "carve up" and "allocate" addresses. Just let the system take care of it...

No more sharing IPs with other customers. Every resource, no matter how tiny can get a dedicated address. Got an S3 bucket with 1KB of files in it? You get your own IP!

Every VM or service sees the real client IP, not the reverse proxy IP.

No need for SNI, ESNI, or even host headers since every web server can have a dedicated IP.

No reverse proxy means that load-balancers can simply set up the TCP handshake and then everything runs directly at wire speed. There is never a need to "scale" a load balancer.

The IPv6 addresses are consistent, globally. The IP address of the cloud VM is the address you register on-premises to SSH to it. No NAT magic involved at any point.

Adding a private link (e.g.: ExpressRoute) doesn't change your address ranges. They're the same, only the routes change. This would be a completely transparent change to your firewall rules of whitelisting setup.

Etc...

PS: The current Azure IPv6 architecture reproduces all of the limitations of their IPv4 architecture. They even NAT the addresses! You literally cannot have any of the above, ever, with Azure using IPv6 as it is now. They even limit the number of IPv6 addresses to further restrict you. If they do fix it, you'll have to redo your entire IPv6 setup. It's insanity.

Re: Improving DNS Privacy with Oblivious DoH

#307

Post by joshspankit »

lawnchair_larry wrote: post #261
joshspankit wrote: post #239

Earlier quoted context omitted.

The bypassing has to do with exerting their control despite user wishes. Hiding “complexity” from users is one method that is at the core of Apple’s brand. Yes, very smart people uncover this kind of thing regularly, but the trend feels like Apple is just trying to refine the process until they have a “perfectly secure” device by virtue of the fact that not even legitimate owners are able to enforce their wishes when…

You’re making assumptions about their motivations, and they’re not correct. They are not doing it despite user wishes. They did it under the reasonable assumption that the user has no such wish. It likely didn’t cross their mind.

Yes. We’re both making assumptions.

Apple is surely aware of Little Snitch and other firewalls, and that the markets for that are dependant on a percentage of users who want absolute insight and control in to their network traffic. Similarly, there are journalists and sources who must by nature be very cautious about all network traffic. It would be hard to argue I think that Apple is unaware of both of these groups of users, and if they are aware; it must follow that it crossed their mind.

Whether that crossing their mind means they discarded it or intentionally chose to go against it may be a question that only gets answered in hindsight since Apple says very little publicly.

Re: Improving DNS Privacy with Oblivious DoH

#308

Post by Lammy »

Kalium wrote: post #304
Lammy wrote: post #298

Earlier quoted context omitted.

Or until your country makes some friends and they decide to share their piece with each other until they recover your whole request.

There is no system that both allows communication between multiple parties and is infinitely resilient to a sufficiently determined, large, and well-funded group of people with guns. What we can do with design and architecture is make each breach of communications security consume greater resources than unencrypted DNS, unencrypted HTTP, and unencrypted email.

There is no bit of land left on Earth where I could go live and not be governed by a determined, large, and well-funded group of people with guns. Perhaps it's time to start building with them in mind first?

Re: Improving DNS Privacy with Oblivious DoH

#309

Post by Kalium »

Lammy wrote: post #308
Kalium wrote: post #304

Earlier quoted context omitted.

There is no system that both allows communication between multiple parties and is infinitely resilient to a sufficiently determined, large, and well-funded group of people with guns. What we can do with design and architecture is make each breach of communications security consume greater resources than unencrypted DNS, unencrypted HTTP, and unencrypted email.

There is no bit of land left on Earth where I could go live and not be governed by a determined, large, and well-funded group of people with guns. Perhaps it's time to start building with them in mind first?

Quite. That said, migrating to new protocols and systems is rather challenging. So we get retrofits like DNS over HTTP, and Oblivious DNS over HTTP.

Historically, radicalism in the form of whole-protocol-suite replacements has often seen little in the way of adoption. Whereas incrementalism in the form of tunnels and other protocol amendments has been much more successful.

Re: Improving DNS Privacy with Oblivious DoH

#310

Post by dylz »

MrStonedOne wrote: post #35

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…

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