[HN Gopher] Improving DNS Privacy with Oblivious DoH
___________________________________________________________________
Improving DNS Privacy with Oblivious DoH
Author : websirnik
Score : 425 points
Date : 2020-12-08 12:33 UTC (10 hours ago)
(HTM) web link (blog.cloudflare.com)
(TXT) w3m dump (blog.cloudflare.com)
| phlhar wrote:
| 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
| cannabis_sam wrote:
| Has Google produced any similar initiatives?
| Lammy wrote:
| 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...
| Kalium wrote:
| 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.
| [deleted]
| nalekberov wrote:
| 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.
| TimWolla wrote:
| Probably better source, the blog post at Cloudflare:
| https://blog.cloudflare.com/oblivious-dns/
|
| See also: https://news.ycombinator.com/item?id=25344220
| dang wrote:
| Thanks! we've changed to that from
| https://techcrunch.com/2020/12/08/cloudflare-and-apple-
| desig....
| aorth wrote:
| Thanks. The original post redirects to:
|
| https://guce.advertising.com/collectIdentifiers?sessionId=3_...
|
| Which is blocked at the DNS level on my network.
| jessmay wrote:
| As it should be.
| benlivengood wrote:
| 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
| jamescun wrote:
| 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.
| snarf21 wrote:
| 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.
| [deleted]
| GoblinSlayer wrote:
| The DNS server is centralized storage of all your browsing
| habits.
| ignoramous wrote:
| 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?
| snarf21 wrote:
| 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.
| [deleted]
| mike_d wrote:
| > 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.
| judge2020 wrote:
| > which doesn't honour the EDNS client subnet extension.
|
| background: https://news.ycombinator.com/item?id=19828702
| fulafel wrote:
| 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?
| jsmith45 wrote:
| > 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.
| baskire wrote:
| Thus increasing the cloudflare value-prop of anycast based load
| balancing.
| absolutelyrad wrote:
| 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).
| jgrahamc wrote:
| 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.
| ignoramous wrote:
| It'd have been fabulous if Cloudflare ran ODoH Proxy too.
| seek3r wrote:
| 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?
| techelite wrote:
| 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 wrote:
| 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).
| techelite wrote:
| Didn't twitter survive?
|
| Also how would we know if Apple is working with other
| companies? It's not like they are known to be transparent
| or Truthful.
| alwillis wrote:
| _Also how would we know if Apple is working with other
| companies? It 's not like they are known to be
| transparent or Truthful._
|
| Apple puts privacy and security front and center as part
| of their brand. They zig while everyone else is zaging,
| trying to make a buck on user data, which they don't do.
|
| For starters, here's their transparency report:
| https://www.apple.com/legal/transparency/
| [deleted]
| arminiusreturns wrote:
| 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 wrote:
| 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...
| MrStonedOne wrote:
| 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?
| new23d wrote:
| _> 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?
| MrStonedOne wrote:
| This is a protocol, not a product. There is no set proxy, or
| resolver.
| new23d wrote:
| 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._
| CyberRabbi wrote:
| 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
| ksm1717 wrote:
| 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 wrote:
| 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.
| andiareso wrote:
| This seems suspicious to me. Apple does most if not all
| ML/data-mining on the device where-as competitors do it in
| the cloud. My assumption is they are positioning themselves
| this way to grab consumers later should regulations hit cloud
| services collecting data externally. Apple can say it is all
| on device and don't have access while other companies will
| have to say they have your data. Ultimately the motives are
| the same.
| ajnin wrote:
| 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.
| jlgaddis wrote:
| 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 wrote:
| Sounds like Tor/Onion Routing?
| eh78ssxv2f wrote:
| 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
| theamk wrote:
| This seems to require DNSSEC as a key function. @tptacek ?
| tptacek wrote:
| It has nothing to do with DNSSEC.
| theamk wrote:
| 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.
| alwillis wrote:
| Thank you for the part regarding DNSSEC--I was just about
| to post the same thing.
| tptacek wrote:
| Oh, gross! I missed that; I read the TechCrunch article and
| thought I understand what they were going for. Thanks for
| the correction. That's disgusting.
| aftbit wrote:
| Can the proxies be (ab)used to proxy arbitrary HTTPS traffic?
| landerwust wrote:
| 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.
| eeZah7Ux wrote:
| """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 wrote:
| 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.
| syshum wrote:
| 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
| [deleted]
| Avtomatk wrote:
| 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.
| bennettnate5 wrote:
| 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.
| throwaway54235 wrote:
| The only solution is onion routing AKA Tor and similar.
| cesarb wrote:
| > 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.
| fsflover wrote:
| > 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.
| sneak wrote:
| 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.
| landerwust wrote:
| 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)
| baskire wrote:
| All I see is a proxy service and a way for cloudflare to get
| access to the data
| diegocg wrote:
| 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?
| Sophira wrote:
| While individual clients may not be easily identifiable,
| there's still a measure of identification that could be
| made, if you were to configure the public key DNS server to
| send a different (but persistent) public key to each IP
| address which asks for the DNS record. (Probably an ISP's
| caching nameserver.)
|
| You can't tell how many people are going to be covered by
| that public key, but you could probably make educated
| guesses, or combine this with other metadata.
| e12e wrote:
| They run both, or buy data from the company that runs the
| other half?
|
| I'm not sure I see the point,tbh. If you want to control
| dns, why not resolve yourself, with whatever cache you
| need? And if you trust a company to do that for you -
| assuming the two companies do log "their half" - you're
| just a data breach, data broker agreement or an acquisition
| away from a commercial entity having all the data (again)?
| ksec wrote:
| I am guessing most if not All future Apple devices / OS will
| default to use Apple Proxy for DNS?
| wil421 wrote:
| 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.
| [deleted]
| [deleted]
| [deleted]
| TimWolla wrote:
| 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?
| GoblinSlayer wrote:
| Abuse. The message must be a DNS query, not arbitrary tor
| traffic.
| landerwust wrote:
| 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
| TimWolla wrote:
| Yes, I understand that. But I don't understand what ODoH does
| better than a run of the mill SOCKS proxy, such as Tor.
| [deleted]
| landerwust wrote:
| Tor is not a run of the mill SOCKS proxy, not least in that
| it inserts arbitrarily high latency into the user data
| path. On the other hand, an actual run of the mill SOCKS
| proxy would have visibility of the user's queries and their
| identity, defeating the purpose of the design.
| TimWolla wrote:
| > an actual run of the mill SOCKS proxy would have
| visibility of the user's queries and their identity,
| defeating the purpose of the design.
|
| Why would it have visibility of the queries? If I send a
| TLS connection (containing my DoH query) through that
| SOCKS proxy, then the SOCKS proxy is unable to decrypt
| that TLS connection without breaking certificate
| verification and thus can't read my DoH query.
| landerwust wrote:
| Very good point! Sorry, I was confusing myself thinking
| about classic DNS.
| ignoramous wrote:
| 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...
| landerwust wrote:
| 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 wrote:
| > 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.
| 1over137 wrote:
| Anyone have any idea why they chose to require
| 'configuration profiles' here?
|
| Also, don't 'configuration profiles' require that your Mac
| have an associated AppleID?
| xoa wrote:
| > _Note that DoH (and DoT) shipped in iOS 14 and Big Sur,
| though aren 't particularly easy to enable._
|
| Specifically, you must install a properly configured
| .mobileprofile with HTTPS/TLS in the DNSSettings >
| DNSProtocol part of the payload (along with DNS server
| addresses of course). Merely pointing at a DoH/DoT
| supporting DNS server in the settings GUI won't do it, the
| OS doesn't do any probing and automatically use it just
| because it's available. For applications DNS Settings is
| covered under the Network Extension framework [0].
|
| It's definitely nice Apple now has this built-in, and since
| they're onboard with Cloudflare/Fastly maybe this new twist
| will be pretty fast too. But obviously they're going to
| have to make this more automated for it to really make a
| widespread difference, ideally it'd simply see if the
| supplied DNS server (manual or DHCP) could run DoH/DoT and
| then just use it by default with no interaction required.
|
| ----
|
| 0: https://developer.apple.com/documentation/networkextensi
| on/d...
| throwaway67239 wrote:
| Also, macOS will not let you enable a DoH profile and
| Little Snitch (or probably any other tool using the
| Network Extension framework) at the same time. I don't
| know if this is a bug or intended behavior, but it's a
| disappointment.
| alwillis wrote:
| _Note that DoH (and DoT) shipped in iOS 14 and Big Sur,
| though aren 't particularly easy to enable._
|
| You can use something like iMazing Profile Editor [1] to
| create a .mobileprofile (which is just XML) to configure
| DoH or DoT.
|
| [1]: https://imazing.com/profile-editor
| xoa wrote:
| Out of curiosity, what's the difference vs Apple's first
| party "Apple Configurator"? Do you like the GUI better,
| or does it expose more options?
| alwillis wrote:
| I do like the UI/UX better; I've always found Apple
| Configurator to be clunky and non-intuitive.
| GoblinSlayer wrote:
| If they allow to configure DoH server, you can use
| https://github.com/DNSCrypt/dnscrypt-proxy
| techelite wrote:
| 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 wrote:
| Do you have actual proof of this or are you just going to make
| misleading claims yourself?
| nalekberov wrote:
| 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?
| GoblinSlayer wrote:
| This buzzword is actually useful though. It gave us ESNI,
| Cambridge Analytica, antimonopoly memes and whatnot.
| xondono wrote:
| Debunked where? If they were I'd expect HN to be the first to
| publish
| techelite wrote:
| Yes, they are here every week.
|
| There are soooooo many examples.
|
| You want iphone security? Google iphone security. Hit news.
|
| You want Apple privacy? Google, Apple privacy. Hit news.
|
| This isn't obscure at all. It's a weekly event.
| MrStonedOne wrote:
| Your statement is 100% correct but misses the entire point
|
| https://nibblestew.blogspot.com/2020/04/your-statement-is-10...
| karmakaze wrote:
| 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 wrote:
| > 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.
| dj_mc_merlin wrote:
| 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?
| John_Westra wrote:
| I would love to see Firefox be an early adopter of this, regain
| market share and save us all from Chrome!
| cblconfederate wrote:
| > 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.
| jgrahamc wrote:
| 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.
| cblconfederate wrote:
| Decentralized spying > centralized spying
| judge2020 wrote:
| Choosing to have google or quad9 spy on you doesn't mean
| AT&T no longer gets your DNS data when you use plain port
| 53.
| akvadrako wrote:
| If anyone wants the draft RFC:
|
| https://tools.ietf.org/html/draft-pauly-dprive-oblivious-doh...
| OJFord wrote:
| 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.
| izacus wrote:
| 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 wrote:
| 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.
| MrStonedOne wrote:
| 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 wrote:
| > 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.
| clashmeifyoucan wrote:
| 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.
| dang wrote:
| 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.
| TrueDuality wrote:
| 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.
| wtetzner wrote:
| 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?
| rsync wrote:
| 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.
| zachm0 wrote:
| Yep! If you have a Raspberry Pi, look into Pihole. Some
| routers have this capability too.
| hkt wrote:
| 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.
| salgernon wrote:
| 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...)
| remarkEon wrote:
| Any "how to" recommendations for setting up something
| similar? I have a pi-hole but after reading this thread I
| feel like im severely under-utilizing it.
| 0x426577617265 wrote:
| Blocking traffic for known DoH services would be trivial. How
| about blocking unknown, how would you block that?
| dhaavi wrote:
| Think out of the box: Just don't let the app connect to an
| IP it has not resolved a domain name for.
|
| That's what we can do with the Portmaster
| (https://github.com/safing/portmaster). Check it out!
| rsync wrote:
| "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 ...
| TrueDuality wrote:
| 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?
| fiddlerwoaroof wrote:
| You can snoop SNI and use that to block traffic, right? In
| another thread, someone suggested also stripping the keys
| for encrypted SNI from DNS queries which, when combined
| with a firewall that attempts to make a DoH query to every
| new SNI name it sees might potentially work.
| specto wrote:
| 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.
| vetinari wrote:
| You can also DNAT all port 53 traffic to your resolver.
| Devices will think they are talking to 8.8.8.8 or whatever,
| but in reality they will ask your resolver and your
| filtering will apply.
|
| Your filtering can still break these devices.
| josephcsible wrote:
| 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.
| saurik wrote:
| 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
| judge2020 wrote:
| 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/
| JoshTriplett wrote:
| This is exactly why browsers support doing their own name
| resolution: because some OSes advance much more slowly.
| 1over137 wrote:
| Why on earth is a "configuration profile" required for
| this?
| judge2020 wrote:
| I imagine Apple is weary about having a UI for this since
| it might cause more bad PR/complaints about people being
| able to get around (for example) school website filters.
| Chrome eased its UI rollout by introducing a managed
| policy that admins could configure before the UI was
| enabled. https://cloud.google.com/docs/chrome-
| enterprise/policies/?po...
| rubyfan wrote:
| 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.
| TrueDuality wrote:
| 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.
| notwedtm wrote:
| 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.
| admax88q wrote:
| 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.
| zamadatix wrote:
| 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.
| TrueDuality wrote:
| 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?
| acdha wrote:
| 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.
| yardstick wrote:
| 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.
| fiddlerwoaroof wrote:
| 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.
| acdha wrote:
| If the network allows outbound traffic, they can hard-code
| an IP list - this is how Cloudflare's 1.1.1.1 works and
| malware has done this for decades - or they can use local
| DNS to resolve a single name which will answer or redirect
| to a service which does further queries. Malware commonly
| used IRC for this until that started getting blocked on
| most networks, but imagine how easy it would be to miss,
| say, a bot which connects on 443 to a major hosting
| provider, like half the apps you run, searches Google.com,
| Twitter, etc., or hits an ad network for a keyword selected
| by the attacker.
|
| In every case, once they get the server(s) to connect to
| you lose all further visibility unless you're blocking 443
| and forcing traffic through an inspection proxy.
| fiddlerwoaroof wrote:
| Yeah, it's an arms race, but I suspect it's solvable: at
| least solvable enough that it's feasible to just not use
| devices that break your policies. For things like Pi-
| Hole, the setup I describe will reduce much of the ad
| noise even without more complicated systems.
| acdha wrote:
| The way to solve is either to segregate unmanaged devices
| onto a separate network and give up on controlling them
| or to implement the system I described. The same Pi
| running a DNS server can run a proxy which applies
| blocking policies on all hostnames.
| SkyPuncher wrote:
| Based on this:
| https://stackoverflow.com/questions/33099569/how-does-
| sock-5...
|
| > Firefox, for example, sends hostname to SOCKS proxy
| without resolving it.
|
| So a simple proxy can bypass local restrictions.
|
| -----
|
| I remember doing something similar back in my IT days just
| to see if it was possible. It was.
| chipb wrote:
| How well does the redirect scheme work for a device that
| connects to a central DNS server listening on, say, port
| 5353 instead? What about 80 or 443?
| jlgaddis wrote:
| https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_goo
| d
| vageli wrote:
| > How well does the redirect scheme work for a device
| that connects to a central DNS server listening on, say,
| port 5353 instead? How about 80 or 443?
|
| Just because it is not a silver bullet doesn't mean it is
| not effective for a large percentage of users.
| fiddlerwoaroof wrote:
| Well, it's more complicated, but in theory you could do
| some deep packet inspection that understands the
| protocols: personally, I'd use this to break DoH
| connections (for every host name seen in SNI, attempt a
| DoH query, if it resolves, reset the connection) and
| attempt to force everything to fall back to plain DNS.
| Then, whitelist a couple outbound ports (on most
| networks, maybe just 443 + 53?) and block VPNs.
| judge2020 wrote:
| > or every host name seen in SNI
|
| Not going to be possible in a few years or so:
|
| https://news.ycombinator.com/item?id=25344311
| dhaavi wrote:
| meh. The outer SNI and the IP address still tell a lot
| about what you are doing online.
| dhaavi wrote:
| With the Portmaster
| (https://github.com/safing/portmaster) we're going in
| that direction, but it will take a couple more years to
| be able to go that deep. Have a look!
| JMTQp8lwXL wrote:
| 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?
| iso947 wrote:
| 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)
| yegle wrote:
| Enterprise can disable DoH in Chrome using a group policy.
| TrueDuality wrote:
| 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 wrote:
| 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.
| crispyporkbites wrote:
| 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.
| gumby wrote:
| > 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.
| kibwen wrote:
| And users get to decide which applications to install.
| Tunneling has been a thing for decades; likewise for
| malicious programs. Vigilance when installing programs on a
| networked device has always been and remains necessary.
| crispyporkbites wrote:
| But it's not under the users control if they install an
| app- there's nothing hard that prevents the abuse. Now if
| the OS had a system wide / network level proxy that checks
| the correct DNS calls are getting made and overrides with a
| user chosen default, then you'd have something.
|
| But we don't, we just have a default
| j16sdiz wrote:
| Because, DNS, like default gateway and ip address, are
| configured by DHCP? Zoned DNS server for intranet is very
| common.
| dhaavi wrote:
| > 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!
| 1vuio0pswjnm7 wrote:
| IMO, the primary benefit of DoH to users is anti-censorship,
| not "DNS privacy", despite the complete absence of the word
| "censor" in the DOH RFC 8484. For example, a growing number of
| ISPs around the world filter DNS, e.g., by port, so, e.g.,
| anything the user sends to port 53 UDP/TCP is redirected to the
| ISP's DNS cache. This makes it easy to block web resources
| based on DNS.^1
|
| The Oblivious DoH draft contains a peculiar requirement (cf.
| option) that oblivious target DNS servers must submit to
| DNSSEC. They "MUST" only use keys from RRs signed according to
| DNSSEC. Assuming that means ICANN's DNS, then a third party and
| not the user is in charge of deciding which domains are
| "authentic". That poses a risk of enabling easy censorship.
|
| "DNS privacy", i.e., hiding origin IP address with proxies, is
| a nice option to have, however it should never be "mandatory"
| to use third parties for DNS. The user should always have the
| option of querying the authoritative DNS servers directly,
| without using third party caches or proxies. That is the only
| true source of the DNS data and the only way to avoid DNS-based
| censorship. I recall in the past seeing some HN comments about
| chaining open resolvers as a means of achieving increased DNS
| privacy; this "oblivious target" idea is not new.
|
| As for the idea of "encrypted DNS", we will never have fully
| encrypted DNS until authoritative DNS providers add support for
| it, e.g., by running CurveDNS. Almost all of what is currently
| described as "encrypted DNS service" actually suffers from the
| same so-called "MITM" issue as Cloudflare's free TLS-enabled
| CDN. Queries are encrypted from user to third party, e.g.
| Cloudflare, but not from third party to authoritative source of
| the web resource, or in this case DNS resource record.
|
| Perhaps the notion of "DNS privacy" is being used as a ruse to
| advance certain business interests that are ultimately in
| direct opposition to user privacy, such as aims associated with
| supporting online advertising. IMO, the simplest solution to
| DNS privacy problem is to keep individual DNS queries off the
| remote network. The simplest analogy I have is Wikipedia. If
| the user downloads the bulk Wikipedia data and serves it on a
| localhost httpd^2, then the remote network has no idea which
| pages the user is viewing or when she is viewing them.
| Similarly, if the user downloads bulk DNS data and serves it on
| a localhost DNS server, then the remote network as no idea of
| what queries the user is making or when she is making them.
|
| I use this approach for speed and reliablity, not privacy
| reasons. It works very well for me. In fact, DoH can be used
| for downloading bulk DNS data as most servers allow HTTP/1.1
| pipelining. Thus, DoH can improve DNS privacy, if used outside
| the browser.
|
| 1. A simple solution in some cases would be remote DNS servers
| also listening on non-standard ports.
|
| 2. http://wiki.openmoko.org/wiki/Offline_Wikipedia_reader
|
| If applications using DoH pose a higher risk in terms of
| unwanted ads, trackers, telemetry and malware-serving domains,
| then it stands to reason the risk-averse user should avoid
| those applications. I use a text-only browser for recreational
| web use. I do not need Chrome, Firefox, etc. to enjoy the web.
| stevepike wrote:
| 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?
| iso947 wrote:
| 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.
| JoshTriplett wrote:
| Then complain about devices that hardcode settings and
| don't allow changing them, rather than complaining about
| people taking what devices could _already_ do and
| standardizing it so that anyone can use it in a more
| uniform way.
| OJFord wrote:
| 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.)
| Denvercoder9 wrote:
| Any firewall worth its salt can do this with IPv6 as well.
| There's nothing on a technical level preventing it.
| TrueDuality wrote:
| 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.
| stevepike wrote:
| Can you explain (or share a link) to some proposal for how
| to enable my pihole to securely talk to upstream resolvers
| but force all embedded devices on my network to go through
| the pihole? Anything that lets my pihole sidestep my ISP
| seems like it'd also work for my xbox.
| TrueDuality wrote:
| I don't have any resources handily available for that. I
| would be truly surprised if pi-hole's don't support DoH
| though so I'd just try searching for something like
| "enabling DoH on a pihole" or similar.
|
| Basically sounds like you've already done the hardest
| parts. Your router is redirecting all DNS traffic to your
| pi-hole, this will prevent any normal unencrypted DNS
| traffic from leaving your local network. You pi-hole will
| be in turn making all the DNS requests. If you turn on
| DoH for the pi-hole all the DNS requests on your network
| will be encrypted.
| hrez wrote:
| Nothing would prevent DOH to use <randomIP>:<randomPORT>
| as a resolver. Be it an application or a device. Pi-hole
| will never see it.
| RossM wrote:
| Using Cloudflare with DoH is documented here:
| https://docs.pi-hole.net/guides/dns-over-https/
|
| You essentially run a little proxy server on your pihole
| setup, and configure pihole to use it as your upstream
| dns resolver.
|
| E.g., a proxy server running at 127.0.0.1:5053 which uses
| the Cloudflare ipv4/ipv6 DNS over HTTPS endpoints. This
| can also use other DoH endpoints as desired:
| /usr/local/bin/cloudflared proxy-dns \ --port
| 5053 \ --upstream https://1.1.1.1/dns-query \
| --upstream https://1.0.0.1/dns-query \
| --upstream https://2606:4700:4700::1111/dns-query \
| --upstream https://2606:4700:4700::1001/dns-query
| judge2020 wrote:
| > force all embedded devices on my network to go through
| the pihole
|
| You can only do this for the devices that respect your
| DHCP-provided DNS config. Even if you redirect all port
| 53 traffic on your network to your pihole, a device can
| make its own (DoH or non-DoH) https connection and gets
| DNS responses via that, bypassing your pi-hole.
|
| This was discussed extensively a few days ago on a thread
| about "72% of smart TVs and 46% of game consoles hardcode
| DNS settings":
|
| https://news.ycombinator.com/item?id=25315172
| gumby wrote:
| > 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 wrote:
| 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 ...
| teddyh wrote:
| 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 wrote:
| 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
| londons_explore wrote:
| When you need a log-log plot to make the performance degradation
| not look so severe, you have issues...
| freebuju wrote:
| 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.
| [deleted]
| alwillis wrote:
| _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.
| freebuju wrote:
| 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...
| alwillis wrote:
| _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 networks, which I setup quite a
| while ago now.
|
| From the Wikipedia article on DoH, emphasis mine: "A goal
| of the method is to increase user privacy and security by
| preventing eavesdropping and manipulation of DNS data by
| man-in-the-middle attacks[1] by using the HTTPS protocol to
| _encrypt the data between the DoH client and the DoH-based
| DNS resolver_.
|
| DNS over TLS (DoT) RFC: "This document describes the use of
| Transport Layer Security (TLS) to provide privacy for DNS.
| _Encryption provided by TLS eliminates opportunities for
| eavesdropping and on-path tampering with DNS queries in the
| network_ , such as discussed in RFC 7626."
|
| The lack of DNS encryption isn't what Apple and Cloudflare
| are addressing; it's that whoever runs the DNS resolver can
| still see the websites you're visiting and ODoH fixes that.
| crumbshot wrote:
| 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.
| diegocg wrote:
| 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 wrote:
| 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.
| wp381640 wrote:
| Add a few more proxy hops and you've effectively reinvented Tor
| eeZah7Ux wrote:
| reinvented Tor, but with extra steps and less security
| asutekku wrote:
| But probably faster.
| theamk wrote:
| .. but the version of Tor which does not raise alarms on
| every corporate firewall/IDS system
| [deleted]
| jaimex2 wrote:
| 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?
| MrStonedOne wrote:
| As it stated in the article, ISPs tracking and selling the
| data.
|
| Exactly that, no more, no less.
| alecco wrote:
| 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 wrote:
| 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).
| joshspankit wrote:
| 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?
| simonh wrote:
| Why would Apple care about hiding Gatekeeper traffic from
| internet providers?
| joshspankit wrote:
| I'm guessing they want to hide it more from users. The recent
| bypassing of local firewalls shows this, for example.
| lawnchair_larry wrote:
| The bypassing has nothing to do with wanting to hide it
| from users Even if they did care about hiding it, they know
| how trivial it would be to discover it, as we already saw
| only hours after the release.
|
| And those lookups have nothing to do with DNS, so this
| wouldn't help nor hurt anything related to that.
| joshspankit wrote:
| 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
| those wishes are counter to Apple's mandates.
| simonh wrote:
| Wouldn't it still show up in netstat?
| joshspankit wrote:
| https://twitter.com/patrickwardle/status/1318465421796782
| 082
| wlesieutre wrote:
| Because it's none of Comcast's business what software I run?
| alwillis wrote:
| _Because it 's none of Comcast's business what software I
| run?_
|
| There's no way for your ISP to know what software you're
| running.
|
| Gatekeeper checks if your app is malware (or not) and if
| its been signed with a valid Apple developer certificate.
| The OCSP look up goes over in the clear currently, but
| that's how OCSP works everywhere. Your DNS provider can see
| the OCSP lookup but that's about it.
|
| Apple is in the process of addressing this; you can read
| the details of how the current process works at
| https://eclecticlight.co/2020/11/16/checks-on-executable-
| cod...
| wlesieutre wrote:
| For most of the software on my computer, the developer
| certificate is enough information to know what software
| I'm running.
|
| Are they going to think I'm running some other piece of
| software signed by Slack Inc.?
| alwillis wrote:
| _For most of the software on my computer, the developer
| certificate is enough information to know what software I
| 'm running._
|
| All your ISP can see is certificate _hashes_ , OCSP
| lookups and DNS queries. It can't know what certificate
| hash is connected to what developer application...
| wlesieutre wrote:
| Presumably that's an unsalted hash so that it can be
| checked against the list of certificate revocations, so
| whether it's a hash or not doesn't do anything for
| privacy. It's the same hash of Slack's dev certificate
| that every other Slack customer is sending.
|
| Anyone snooping the connection can figure that out and
| see that my computer said "Check the revocation status of
| Slack Inc.," and the same goes for literally every other
| software company's certificate hash.
|
| I'm glad it's being fixed but it's still bad that it was
| done this way in the first place.
| selfhoster11 wrote:
| It's not hard to match up a certificate hash to the
| issuer, because most issuers will likely only have a
| couple of certificates to simplify internal PKI. It's
| something that can be solved with a rainbow table, there
| aren't even salts involved.
| ChrisRR wrote:
| 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
| alwillis wrote:
| _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.
| PartiallyTyped wrote:
| 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.
| joshspankit wrote:
| I see your point about how they (will) position it, but I'm
| still curious about their actual motives.
| PartiallyTyped wrote:
| Exactly that. It strengthens their image amidst the whole
| ordeal with app signatures. It is equivalent to investing
| for an ad.
| Kalium wrote:
| As a preface, I am about to describe something I personally
| view as _absolutely horrific_. Please, dear reader, in no
| way interpret these comments as approving.
|
| Privacy is a luxury. It's something rich people buy and
| poor people can't afford to concern themselves with. Apple
| sells a luxury product, and has no particular stake in
| invading customer privacy at the moment (iAd was never
| successful enough to change that). So they add a feature to
| their status symbol to address the concerns of their
| customer base and work with a partner company that can
| actually deploy it.
| thrwaway2020aug wrote:
| 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?
| darkwater wrote:
| 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
| throwaway54235 wrote:
| 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.
| acdha wrote:
| 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.
| judge2020 wrote:
| 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
| ReactiveJelly wrote:
| > 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 wrote:
| > _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.
| sroussey wrote:
| 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).
| Kalium wrote:
| I think you've nailed the core of it.
|
| Managing traffic over your network and the devices on your
| network are very similar tasks that aim to accomplish very
| similar things. However, they are not equivalent tasks.
| Relying on traffic management to accomplish device
| management eventually runs into conflicts. These may stem
| from unmanaged devices, guest devices, unmanageable
| devices, or the consequences of the total lack of
| authentication and authorization.
|
| Ultimately, managing traffic and managing devices are not
| tasks that replace one another.
| JoshTriplett wrote:
| 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.
| ignoramous wrote:
| 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 wrote:
| 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.
| [deleted]
| darkwater wrote:
| 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 :(
| mmis1000 wrote:
| 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.
| josephcsible wrote:
| 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.
| jgrahamc wrote:
| About getting rid of SNI...
| https://blog.cloudflare.com/encrypted-client-hello/ Been
| working on that also.
| darkwater wrote:
| 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.
| zero_deg_kevin wrote:
| 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.
| gwbas1c wrote:
| 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.
| selfhoster11 wrote:
| Mobile OSes already support per-application network usage
| breakdowns. This is an OS-level feature, and not an ISP-level
| feature.
| joshspankit wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| xxpor wrote:
| The fcc will have something to say about that. They've
| already banned rules against antennas and sat dishes for
| TV.
| lawnchair_larry wrote:
| Faked? What other reason would an HOA have to ban them?
| g42gregory wrote:
| 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 wrote:
| What's stopping your PiHole from just getting its own HTTPS
| cert?
| g42gregory wrote:
| 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?
| 1over137 wrote:
| >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.
| throwaway54235 wrote:
| 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 wrote:
| 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.
| [deleted]
___________________________________________________________________
(page generated 2020-12-08 23:00 UTC)