[HN Gopher] Encrypted Client Hello
___________________________________________________________________
Encrypted Client Hello
Author : cosmosgenius
Score : 92 points
Date : 2023-09-29 13:27 UTC (9 hours ago)
(HTM) web link (blog.cloudflare.com)
(TXT) w3m dump (blog.cloudflare.com)
| Al0neStar wrote:
| Everytime someone mentions Cloudflare, i think about this article
| [0].
|
| [0] https://blog.cr.yp.to/20230609-turboboost.html
| assassinator42 wrote:
| This is going to make it even more of a pain to do egress
| filtering on networks/systems we administer. I want to be able to
| allow list sites with dynamic IPs. The existing solutions for
| doing this by examining SNI are already often bypassable by
| forging the SNI (looking at you, AWS Network Firewall).
| josephcsible wrote:
| You're supposed to do that kind of filtering on the endpoint.
| If it's possible anywhere else, then it could be used to censor
| other people's computers.
| LinuxBender wrote:
| CF explain how to do this here [1]. Have your local DNS
| resolvers filter the HTTPS _type of DNS queries_ on your DNS
| servers. One example from Microsoft [2]. Unbound would probably
| need a patch though a work-around could be an iptables string
| filter or u32 filter for the record type. There is a DNS module
| [3] for iptables but it is not part of any default
| installations AFAIK.
|
| The second way is to return a "no error no answer" or an
| NXDOMAIN response to queries made to the use-application-
| dns.net.
|
| I personally already use the second option to block DoH and
| cell phones seem to automatically figure out to use port 853
| for DNS-Over-TLS on my home router _Unbound DNS_. I also null
| route most of the public DoH servers. People point out that DoH
| can be on any CDN IP but it never has been.
|
| [1] - https://developers.cloudflare.com/ssl/edge-
| certificates/ech/
|
| [2] - https://learn.microsoft.com/en-us/windows-
| server/networking/...
|
| [3] - https://github.com/mimuret/iptables-ext-dns
| bscphil wrote:
| This only works because browser vendors have taken the
| totally bullshit approach of "you're only allowed to use ECH
| if you have DoH enabled", even though they're really
| unrelated technologies. Related Mozilla bug:
| https://bugzilla.mozilla.org/show_bug.cgi?id=1500289
|
| Of course this kind of filtering is useless to stop a
| determined user (in a bring-your-own-device environment)
| because they can trivially just run their own DoH endpoint.
| Thoreandan wrote:
| Naive question, In 2023 how does DNS-over-HTTP (DoH) affect
| things like the Cisco Distributed Director / F5 3-DNS where DNS
| is used to control which datacenters customer traffic is going
| to? Is this still a technology smaller sites can use?
| depingus wrote:
| I feel like this is only possible because Cloudflare is already
| so huge. If this becomes widely adopted, anyone who wants to
| offer "private" access to their site will have to move through
| Cloudflare. This can't be good.
| josephcsible wrote:
| That's not something Cloudflare decided, though. It's just a
| fundamental limitation on how the Internet works. The
| destination IP needs to be visible to intermediate nodes so
| that they know how to get it there, so the only way to get this
| kind of privacy is for lots of services to be hosted behind the
| same destination IP. And keep in mind that it's not Cloudflare
| exclusive. Any similar service that does large-scale name-based
| virtual hosting will also give you the same privacy benefit
| with this.
| andrewaylett wrote:
| I'm absolutely not offering to implement it, but it does seem
| like one ought to be able to proxy the inner hello to the
| origin so the owner of the shared IP address doesn't actually
| get to inspect the content of the TLS stream.
|
| So if you have a few folk who each want to self-host, you can
| group together to provide ECH across all your sites without
| leaking to each other more than you leak to any passive
| attacker today.
| galadran wrote:
| Any provider can deploy ECH, it's standardized at the IETF.
| Cloudflare are just first.
| depingus wrote:
| Thanks for the info. This feels a little better. I can still
| envision only a handful of "providers" becoming the defacto
| gatekeepers to a private web. I'm gonna have to give this
| some more thought though.
| Avamander wrote:
| A lot of shared hosting providers would also be able to
| implement this. Bringing the benefits of ECH's anti-snooping to
| many end-users outside of CloudFlare.
|
| Individual servers hosting one single website won't benefit
| much though. Unless you do encrypted split-DNS, I guess.
| depingus wrote:
| Thanks for the info.
| makeworld wrote:
| If I host my website on a VPS, is ECH possible? Seems like it's
| only useful when IP addresses are shared across a bunch of sites.
| politelemon wrote:
| If I'm understanding the draft correctly, I think the webserver
| you're hosting your sites on would need it implemented as it
| requires private keys and ECH configuration. In the example of
| nginx since it uses openssl, openssl would need to implement
| it. I found an issue on their Github but it's still open:
| https://github.com/openssl/openssl/issues/7482
| cosmosgenius wrote:
| ECH can be enabled depending on the Terminating TLS server
| used. (not sure which one implements it now) But you are right
| in the sense its used for multiple sites to one IP. Essentially
| ECH is protection for SNI, ALPN, which are plaintext in non-
| ECH.
| dilyevsky wrote:
| Yes, but if you use dedicated IP it is kind of like pointless.
| If you use shared IP of your VPS provider (or Cloudflare) then
| yes fr
| dilyevsky wrote:
| It seems like the same result could easily be achieved by
| widespread Domain Fronting support (e.g set sni to cloudflare-
| sekrit.com and Host: header to the actual domain). Can someone
| explain why this wasn't adopted more widely (I know CF, for
| example, disabled theirs)?
| galadran wrote:
| I believe CF and others buckled under pressure from major
| websites which didn't want to be used as fronts for other
| website's traffic. ECH fixes this because individual sites get
| to opt-in to using it.
| dilyevsky wrote:
| You could just as easily make df opt-in. Another way is to
| use "fake" cloudflare-df.com sni just like they are doing
| with cloudflare-ech.com outer sni
| fivre wrote:
| i find the OP rather amusing--one of the earlier incidents
| during my time at Cloudflare (circa 2015) was dealing with
| prolific domain fronting, where IIRC some third-party proxy
| tool had set something up to the effect of "send SNI query for
| unblocked site on CF network, send HTTP Host for blocked site"
| automatically. this was ultimately blocked less because it was
| strictly undesirable and more because it resulted in some sort
| of cache poisoning problem. the unintended use started serving
| those proxy hack results to regular, non-domain fronting
| requests for whatever reason, which is obviously bad--you want
| the CDN to serve normal requests correctly, so you squash
| abnormal requests that work on their own, but cause cascading
| problems for other not abnormal requests.
|
| many years down the road this is now an actual (with the
| problem cases handled) feature!
| jeffmcjunkin wrote:
| For whatever reason, Domain Fronting is considered more of an
| attack behavior, used by red teamers and penetration testers.
| Doubling down on that behavior likely didn't seem as appealing
| from a PR perspective.
| andrewaylett wrote:
| That relies on the user knowing that they can trust the
| certificate they use as the front in lieu of the certificate
| for the domain they actually want. Which is sub-optimal from a
| security point of view -- unless you complete a handshake with
| a valid certificate for the domain you're actually visiting,
| how _do_ you know that the server you 're talking to actually
| has a valid certificate?
|
| In ECH, we still only complete one handshake per session. If
| you've got the right key for the inner client hello, you'll
| complete a handshake with the certificate for the domain you're
| trying to visit. If not, you'll complete a handshake with a
| certificate for the domain in the outer hello and the server
| will send you the correct key so you can try again with a new
| session. The client gets to validate the right certificate.
| gray_charger wrote:
| This just sounds like a less private Tor.
| Avamander wrote:
| Just like Dropbox is an improvement over FTP with SVN?
|
| I'm only half-joking though. ECH is already being widely
| enabled in clients, it will exceed Tor's adoption massively.
| Not as private, but (much more) usable.
| josephcsible wrote:
| But without having to set up Tor or suffering any of the
| downsides of using it. And if you do want all the privacy of
| Tor, this doesn't stop you from using it.
| ploum wrote:
| If I understand this right, it is basically "cloudfare will
| appear like a huge web server for anybody watching".
|
| This looks like one more attempt by cloudfare to recentralize the
| web. And it doesn't address the issue that cloudfare still
| perfectly know which website you are visiting.
|
| Did I miss something?
| josephcsible wrote:
| It's not making the Web any more centralized. It's a silver
| lining we get due to how centralized it already is.
| cryptonym wrote:
| You are correct, this is how a CDN typically works. Cloudflare
| know who you are and got full deciphered observability (can
| also tamper) for all your traffic with the websites using their
| services. ECH is not meant to change this fact, you still trust
| Cloudflare with all communications to their customers.
| Aissen wrote:
| In this case, the centralization is an advantage for privacy,
| depending on how you look. Basically, no one can guess who you
| are trying to connect to by looking at the packets (modulo
| fingerprinting...).
|
| This is bad if you are a government, company, school or user
| that wants to inspect traffic coming out of black-box devices:
| it's harder to block all of Cloudflare. But this is good if you
| live in a country where service X is blocked because it
| threatens the local political power. For example, when Signal
| was blocked in some countries, it used a method named domain
| fronting to work around that. It relied on a mismatch between
| SNI and HTTP domains, and all CDNs blocked it in the end. ECH
| allows having the same result but with plausible deniability
| for the CDN.
|
| Now of course, there's always a catch... Cloudflare used to
| provide its services to kiwifarms; and what constitutes a
| legal, or moral thing to do tends to vary around the world.
| politelemon wrote:
| I'm not seeing it. It looks contradictory what they're saying.
|
| > This means that whenever a user visits a website on Cloudflare
| that has ECH enabled, no one except for the user and the website
| will be able to determine which website was visited.
|
| But if you look at the inner/outer SNI part:
|
| > The outer SNI is a common name that, in our case, represents
| that a user is trying to visit an encrypted website on
| Cloudflare. We chose cloudflare-ech.com as the SNI that all
| websites will share on Cloudflare. Because Cloudflare controls
| that domain we have the appropriate certificates to be able to
| negotiate a TLS handshake for that server name.
|
| > The inner SNI contains the actual server name that the user is
| trying to visit. This is encrypted using a public key and can
| only be read by Cloudflare. Once the handshake completes the web
| page is loaded as normal, just like any other website loaded over
| TLS.
|
| So Cloudflare sees it? That's definitely not the same as what
| they're describing, it's more of a wink-wink Applesque "trust me
| bro" style of "privacy" - a consolidation of traffic under the
| pretext of something else.
|
| I also looked at the draft document they linked, and that seems
| to match up with what I'm understanding.
|
| > If ECHClientHello.type is outer, then the server acts as a
| client- facing server and proceeds as described in Section 7.1 to
| extract a ClientHelloInner, if available.
| stefan_ wrote:
| You are missing the big picture. Of course CF still sees it -
| they need to route your request somewhere (remember why SNI is
| a thing at all and we don't just use DNS) and you are after all
| choosing to talk to a CF server. But it means not everyone on
| your network that happens to see your traffic can trivially see
| you are visiting pornhub.com
| e12e wrote:
| Not sure if it was edited, but TFA states near the top now:
|
| > This means that whenever a user visits a website on
| Cloudflare that has ECH enabled, no one except for the user,
| Cloudflare, and the website owner will be able to determine
| which website was visited.
|
| Which sounds more precise and correct. I very much agree that
| these details matter.
| jacooper wrote:
| Generally cloudflare assumes itself as being a part of the
| website. Its not the fiest time they did this.
| morpheuskafka wrote:
| Doesn't Cloudflare already terminate TLS anyway? As far as TLS
| is concerned, Cloudflare is "the website."
| galadran wrote:
| The point is that network operators can't tell which website
| the user is visiting, as it could be any of the sites hosted by
| the ECH provider.
|
| In this case, Cloudflare are acting as the ECH provider and as
| they already host the websites, they already see the connection
| plaintext.
| cosmosgenius wrote:
| Cloudflare sees it here because the TLS is closed at Cloudflare
| end. ECH main point is the prevent traffic snooping by ISPs. In
| India a lot of websites are blocked due to gov regulations.
| Those blocks are implemented via the inspection of the
| ClientHello packet to know which website are being accessed.
| Hopefully this will prevent such blocks.
| TrueDuality wrote:
| You're absolutely right, Cloudflare will still see it. That
| doesn't make this a bad improvement though. You don't have to
| use Cloudflare to support it, but it helps obscure which site
| is being visited by the nature of Cloudflare hosting so many
| different sites.
|
| So what does this actually protect against? Who will this
| benefit? Mostly people in censored countries and companies.
| This removes the last piece of information that can be used to
| block HTTPS traffic based on the site your visiting without
| being a party to the exchange.
|
| I still think DoH is hot garbage and the way it has been
| implemented across browsers is an atrocity. It's actively
| harmful to security even if the spirit is in the right place.
| I've got no complaints about ECH.
| AnthonyMouse wrote:
| > You're absolutely right, Cloudflare will still see it. That
| doesn't make this a bad improvement though.
|
| You can do something like ECH in a way that not even
| Cloudflare will see it (it being the connection contents
| rather than the name, since Cloudflare actually needs the
| name to route the connection).
|
| The naive way to do it is to do one handshake with Cloudflare
| that the client uses to provide the "real" name and then
| another with the "real" server so Cloudflare can't see that.
| That is _possible_ but then you 'd need two handshakes, which
| is rather inefficient and probably means it wouldn't be used.
| The interesting question is can someone come up with a way to
| get that result without the inefficiency.
| YeBanKo wrote:
| > You can do something like ECH in a way that not even
| Cloudflare will see it
|
| How is it possible for a Cloudflare to front a website,
| without knowing what the website it is. You browser is only
| supposed to do a handshake with a server with a certificate
| matching the domain, this make Cloudlare in charge of the
| cert. And Cloudflare needs to forward the traffic to a
| known location, so they __have__ to know the target host.
| AnthonyMouse wrote:
| _it being the connection contents rather than the name,
| since Cloudflare actually needs the name to route the
| connection_
| vasachi wrote:
| > This removes the last piece of information that can be used
| to block HTTPS traffic based on the site your visiting
| without being a party to the exchange.
|
| And that will cause blocks by IP. It's not like authorities
| in those countries care that much if a user can't access a
| not-blocked site, as long as they can't access a blocked one.
| josephcsible wrote:
| The point of efforts like this is exactly to make selective
| blocking infeasible. This will force the bad guys to choose
| between blocking nothing and blocking everything, and with
| the exception of North Korea, most aren't willing to do the
| latter.
| vasachi wrote:
| Nope, the bad guys don't care that much.
| jamespo wrote:
| Who are you talking about?
| YeBanKo wrote:
| > I still think DoH is hot garbage and the way it has been
| implemented across browsers is an atrocity.
|
| Not sure if it's a hot garbage, but I don't see why it's
| better than DoT or DoQ, except maybe a use case for censored
| countries. DoT is faster and can be abstracted away from from
| HTTP. Presumably, DoH is more privacy preserving, because it
| runs on the same port and looks just like the rest HTTPS
| traffic. But I think a spying ISP can probably guess that
| it's a DNS traffic by where it's going. If it's an HTTPS
| connection over 443 going to a know DNS server, then it's
| probably a DNS request, thus I don't see added privacy here.
|
| But from traffic administration, it is harder. As a an
| example, now your Smart Spying Device can phone home and it
| is going to be harder to block it.
|
| Also, we are moving from your ISP knowing too much about you
| to Cloudflare knowing too much about you. It's one of the
| biggest DoH DNS services, often they see unencrypted HTTPs
| traffic, they also an exit node for iCloud Private Relays.
| ISP is left out, but Cloudflare seems to be able to
| consolidate this knowledge.
| tialaramex wrote:
| Deployability is what matters. DoH had great deployability
| because everybody speaks HTTPS.
|
| In my home, lots of technologies would work. I have static
| v4 and v6, I have complete control over the firewalls, I
| can do whatever I want. But at my mum's house, who knows
| what ports work and which protocols work over them and
| whether you can change any of that.
|
| HTTPS definitely works though, because if it didn't her web
| browser wouldn't work and she'd yell at the ISP until they
| fixed it. So that's why DoH.
| johnklos wrote:
| I agree that this is generally a good thing, and that DoH is
| an absolutely shitty thing, but I think the poster here was
| taking exception to this statement:
|
| "no one except for the user and the website will be able to
| determine which website was visited"
|
| That, I think we can all agree, is patently untrue.
| Cloudflare shouldn't be publishing blatant deceptions.
| leihca wrote:
| Author here - definitely not trying to be deceptive! I've
| amended the sentence you mentioned to be more clear.
| johnklos wrote:
| Thank you, and good to know :)
| kreetx wrote:
| What is wrong with DoH?
| johnklos wrote:
| It takes our control over our networks away from us and
| gives it to random applications, to Trojans, to viruses, to
| adware purveyors, to advertisers.
|
| It makes the assertion that because SOME of us don't know
| how to change our DNS servers, they (Mozilla, Cloudflare,
| other proponents of DoH) need to take control away from us
| and need to send our DNS lookups to, usually, them.
|
| The justifications are ridiculous, but the harms introduced
| by DoH are much, much worse than the thing they're trying
| to say makes DoH useful.
| josephcsible wrote:
| > It takes our control over our networks away from us
|
| Taking control away from the owner of _networks_ is a
| good thing. Control is supposed to reside with the owner
| of _endpoints_. To see why, imagine if your ISP started
| to MITM all of your connections that went over their
| network.
|
| > don't know how to change our DNS servers
|
| It's not a case of "don't know how". It's a case of
| "can't, because even if you change the setting, $evil_isp
| will hijack the queries anyway".
| johnklos wrote:
| That's an incorrect oversimplification.
|
| It takes control away from the owner of networks, even
| when we're the owner of those networks. Should DoH start
| to become more common, blocking it will become a
| Sisyphean task.
|
| It takes control away from the owner of endpoints. Sure,
| you can go and change the settings in Firefox to turn off
| DoH after they've turned it on without asking and without
| telling us, but what happens when applications and
| Trojans start doing DoH lookups, skipping our system's
| configured DNS? So yes, your statement about control
| residing with the endpoints is correct, but DoH removes
| control, doesn't add it.
|
| For the case of "can't, because even if you change the
| setting, $evil_isp will hijack the queries anyway",
| that's FUD. There are many, many better ways to deal with
| evil ISPs.
|
| Encouraging the world to send all of their DNS lookups to
| a centralized entity like Cloudflare (who, by every
| right, are precisely in a position to be an evil ISP) is
| such an incredibly shortsighted idea that I have to think
| that you haven't thought out the implications of a world
| where DoH is dominant.
|
| If you care to learn, consider things without DoH: you
| can edit your hosts file. You can choose your DNS
| servers. You can run a local recursive resolving DNS
| server. You can block ads and advertisingware using your
| DNS server and/or something like Pihole. You can block
| all DNS queries to the outside world on your network so
| that they all go through your own resolvers.
|
| Next, consider a world where DoH is commonplace: you have
| no control over DNS lookups on your own system. Your only
| choice is to not run binaries that might do things you
| don't like. Want to block ads or adware, or adult sites,
| or conspiracy sites, or any of a number of other things
| on the Windows system that your child uses? Now Edge
| doesn't let you. Want to block the Trojans and phishing
| sites that Google serves through their ad network? Chrome
| doesn't let you. "Just don't run binaries that do that"
| is one heck of an ask for people who don't know how to
| set their own DNS or who have an evil ISP.
|
| You can block common DoH servers, until Cloudflare puts
| them on the same address as the endpoints for their
| millions of hosting customers. But what happens when apps
| do DoH lookups using random Amazon AWS or Google Cloud
| servers? How do you block them? Do you block ALL https?
|
| You see, you'd give up freedom, and have everyone else
| give up their freedom, for some abstract "safety" from
| ISPs that use your DNS data. You'd apply a shitty fix for
| 1% of the people to 100% of the people, rather than
| create tools for the 1% to circumvent their evil ISPs.
|
| The fact that you'd choose this makes me think that
| either you want big, evil companies like Cloudflare to
| win, or you really don't understand the issues.
|
| Just like this article above does a good job explaining
| the lack of security in the cloud, we really could use a
| good article explaining how completely inane the idea of
| DoH is.
| hkt wrote:
| As jeremiads go, this is golden. I for one and persuaded
| and am grateful you wrote it.
|
| I hadn't considered before that DoH effectively takes an
| avenue away from people who want to block advertising and
| trackers. This makes it a fiercely unpleasant thing
| working against users.
|
| Personally, I'm switching to DNS over TLS instead.
| Avamander wrote:
| > but what happens when applications and Trojans start
| doing DoH lookups, skipping our system's configured DNS?
|
| Exfiltration has always been a problem. But it's not a
| good reason to make MITM possible.
|
| Network control should not give control over endpoints
| any degree more than is necessary to deliver packets from
| point A to B. We can't trust them with more.
|
| > [...] Now Edge doesn't let you.
|
| That's blatantly false for normal endpoints though. Be it
| an AV or parental controls, an endpoint administration
| will have that ability to intercept.
|
| If an endpoint doesn't let you do thay then to be honest,
| you've already lost the battle. Even simple HTTPS is not
| really filterable.
|
| > Just like this article above does a good job explaining
| the lack of security in the cloud, we really could use a
| good article explaining how completely inane the idea of
| DoH is.
|
| What is actually inane is the amount of implicit trust
| and control given to networks right now. Your network
| might be a nice wonderland, but many aren't.
| johnklos wrote:
| People own their networks when they're not out in public.
| Again, solving for a problem with public networks by
| forcing shortcomings on to all networks is shortsighted
| and ill conceived.
|
| "But it's not a good reason to make MITM possible" is
| disingenuous. Avoiding DoH doesn't make MITM possible,
| just as adding DoH doesn't save us from MITM. It does,
| though, save apps / Trojans from MITM, particularly when
| we're the ones who want to be in the middle :P
|
| "That's blatantly false for normal endpoints though. Be
| it an AV or parental controls, an endpoint administration
| will have that ability to intercept."
|
| Go ahead and tell me how to remove Edge, or how to have
| Windows open links in other browsers, without involving
| third party software that forces this, then tell me how
| "endpoint administration" is something we can expect of
| people who can't set their own DNS (or who have evil ISPs
| and can't set up any of a number of other ways to
| circumvent said evil ISPs).
|
| You didn't address the real meat of the issue: Why is
| avoiding one issue - ISPs tracking DNS - worth all the
| bad things that come with it? The only explanation that
| makes sense to me is that it's worth it to companies that
| want to control as much as they can, like Cloudflare.
|
| "What is actually inane is the amount of implicit trust
| and control given to networks right now." So instead of
| teaching people how and encouraging them to make their
| networks better, you'd rather divest some of that trust
| to companies like Cloudflare, and to every application /
| Trojan writer? Right - because the amount of data
| collection in software isn't a problem at all. We just
| need to trust them, and they'll do right by us.
|
| You've made my point for me that you, and other
| apologists for DoH, haven't really thought things
| through, have you?
| josephcsible wrote:
| > People own their networks when they're not out in
| public. Again, solving for a problem with public networks
| by forcing shortcomings on to all networks is
| shortsighted and ill conceived.
|
| It's not just being out in public. Even when you're home,
| you're still at the mercy of your ISP.
|
| > Go ahead and tell me how to remove Edge, or how to have
| Windows open links in other browsers
|
| What does preventing use of Edge have to do with DoH?
|
| > You didn't address the real meat of the issue: Why is
| avoiding one issue - ISPs tracking DNS - worth all the
| bad things that come with it?
|
| You've yet to convincingly point out a single bad thing
| that actually comes from DoH.
|
| > So instead of teaching people how and encouraging them
| to make their networks better, you'd rather divest some
| of that trust to companies like Cloudflare, and to every
| application / Trojan writer?
|
| You can't make public Wi-Fi or your ISP's network better
| no matter how knowledgeable you are.
| johnklos wrote:
| "Even when you're home, you're still at the mercy of your
| ISP." No, I'm not. If you think I am, then you don't
| understand networking.
|
| "What does preventing use of Edge have to do with DoH?"
| If you can't have basic control of programs on your own
| computer, tell me how you're going to control programs'
| use of DoH.
|
| "You've yet to convincingly point out a single bad thing
| that actually comes from DoH." I've named many: we lose
| the ability to block ads, adware, Trojan CaC, spyware, et
| cetera. We lose the privacy of our own DNS lookups. Your
| suggestion seems disingenuous.
|
| "You can't make public Wi-Fi or your ISP's network better
| no matter how knowledgeable you are." No - YOU can't or
| don't want to, because you don't understand networking.
| People who want to can, though, and this is what I'd
| encourage, instead of enshittifying the Internet by
| believing companies like Cloudflare when they tell us our
| ISPs suck and we should just trust them instead.
| WorldMaker wrote:
| > People own their networks when they're not out in
| public.
|
| People _rent_ their networks from one, maybe two area
| options. The consumer networks want to completely control
| router hardware these days and these days charge _extra_
| rental fees for owned hardware instead of rented
| hardware. (It 's fascinating that they can legally get
| away with that.) Some of the biggest consumer networks
| have already proven they are happy to use this hardware
| control to inject additional ads into customers' networks
| for a paltry amount of additional revenue.
|
| You are correct that people _should_ have networks that
| they own and trust at home. You may have missed that they
| don 't and consumers have lost that battle. (You may also
| be underestimating just how much time people spend on
| devices "out in public". The mobile device has become the
| most common device for a lot of users. For some users the
| only device.)
|
| > every application / Trojan writer
|
| They've always had that power.
|
| Applications have never been forced to use OS/network-
| configured DNS. DNS is an absurdly simple protocol that
| doesn't even have encryption by default. OS firewalls
| _might_ block sockets to DNS ports by default, but there
| are ways to tunnel over other ports plus tools like UPnP
| given enough user trust.
|
| DoH is a standardized port tunnel but that doesn't mean
| that unstandardized ones never existed before.
| Trojans/viruses have been doing weird things to avoid DNS
| for decades. DoH doesn't make them that much easier.
|
| DoH _isn 't great_ and it is a shame that for privacy and
| control it's a big ugly trade-off/compromise from ideals.
| It's useful for _some_ people. There are definitely
| unanswered questions in terms of which big corporation
| truly cares about privacy. I 've seen my monopolist
| consumer ISP inject ads against my wishes and do change
| the DNS on my home (owned) routers (that I pay extra for
| each month despite owning my own hardware because of
| owning my own hardware). I don't always know what to
| think about Cloudflare's massive PR engine of how much
| they claim to value privacy, but so far I've never seen
| them inject an ad where one doesn't belong nor have I
| seen ad revenue make a splash in their quarterly reports.
| They don't seem to be an ad company. (Yet?)
|
| Trust is hard and we all have different threat models. I
| don't blame you for distrusting Cloudflare. I have direct
| evidence for distrusting my current ISP and indirect
| evidence for distrusting most consumer ISPs I've
| encountered, despite being paying customers. There's no
| free lunch and there's no right answer, just a lot of
| "least wrong" answers. DoH isn't the right answer
| objectively. But DoH can be a "least wrong" for some
| users. Just as trying to be the MITM in networks you own
| is quite wrong from a security standpoint (once you've
| got one MITM it becomes harder to trust that there isn't
| a second one) but may be the "least wrong" answer for
| some users including maybe you.
| AnthonyMouse wrote:
| > People _rent_ their networks from one, maybe two area
| options.
|
| That's not the LAN.
|
| > The consumer networks want to completely control router
| hardware these days and these days charge _extra_ rental
| fees for owned hardware instead of rented hardware. (It
| 's fascinating that they can legally get away with that.)
|
| You can put your own router behind theirs. It's
| ridiculous for them to make you do that but nothing
| actually stops you.
|
| > You may also be underestimating just how much time
| people spend on devices "out in public".
|
| For which anyone can use a VPN.
|
| > Applications have never been forced to use OS/network-
| configured DNS. DNS is an absurdly simple protocol that
| doesn't even have encryption by default. OS firewalls
| _might_ block sockets to DNS ports by default, but there
| are ways to tunnel over other ports plus tools like UPnP
| given enough user trust.
|
| Your local network can intercept ordinary DNS queries to
| any server and redirect them to your own. To work around
| this, a piece of malware would have to contact some
| custom server on a different port to do a name lookup --
| but where does it look up _that_ server 's IP address?
| Hard-coding the IP address allows the malware's lookup
| server to be blocked.
|
| But if centralized DoH servers become too popular to
| block because blocking them breaks too many legitimate
| applications, now the malware can use them and the user
| can't block them.
|
| > I don't always know what to think about Cloudflare's
| massive PR engine of how much they claim to value
| privacy, but so far I've never seen them inject an ad
| where one doesn't belong nor have I seen ad revenue make
| a splash in their quarterly reports. They don't seem to
| be an ad company.
|
| The question is, what are they doing with the data they
| collect?
|
| > There's no free lunch and there's no right answer, just
| a lot of "least wrong" answers.
|
| There is already a "least wrong" answer: Use a VPN you
| trust and use your VPN's DNS or run your own. VPNs have
| plenty of competition, and you can set up your own on any
| hosting provider, which also have plenty of competition.
|
| This is basically the same thing as having Cloudflare do
| it over TLS, except that it's not centralized and remains
| in the control of the user, so is better.
| johnklos wrote:
| Trust is hard, yes. Cloudflare might not be going for the
| low hanging fruit such as injecting ads, but they clearly
| want to be a monopoly around whom the Internet
| recentralizes.
|
| Moving DNS from an ISP, who we pay and with whom we have
| legal contracts, to a company that does things,
| supposedly, for altruistic reasons, with whom we do NOT
| have contracts, doesn't fix anything. It makes things
| worse. The solution is to remove DNS from your ISP and
| run it yourself, or use a not-for-profit that isn't
| trying to become a monopoly, that isn't in a position to
| have its data syphoned off by the NSA, that doesn't
| knowingly and willingly host spammers, phishers and
| scammers.
|
| How about we don't trust ISPs AND we don't trust
| Cloudflare?
|
| BTW - I have to flatly disagree with your suggestion
| that, "once you've got one MITM it becomes harder to
| trust that there isn't a second one". That's ridiculous.
| I can check and verify things to a much greater degree by
| running my own network. Also, I never said anything about
| MITM my own network. I want to run my own DNS and block
| DNS to the rest of the Internet. That's not MITM.
|
| The least wrong thing is to not replace something that
| MIGHT be shitty with something that MIGHT also be shitty,
| but might also open you to new problems and security
| issues. The idea that it MIGHT be less shitty isn't a
| good enough reason for DoH.
| josephcsible wrote:
| > It takes control away from the owner of networks, even
| when we're the owner of those networks.
|
| My point is that even when you are the owner of a
| network, you shouldn't have control of traffic on it
| between endpoints that you don't own either of.
|
| > what happens when applications and Trojans start doing
| DoH lookups, skipping our system's configured DNS?
|
| The Trojans could just hardcode the IP instead, so
| blocking DoH wouldn't magically guarantee you could catch
| them with DNS.
|
| > So yes, your statement about control residing with the
| endpoints is correct, but DoH removes control, doesn't
| add it.
|
| Which programs specifically don't let the user disable
| DoH? If none, then how does its presence remove control?
|
| > For the case of "can't, because even if you change the
| setting, $evil_isp will hijack the queries anyway",
| that's FUD. There are many, many better ways to deal with
| evil ISPs.
|
| Such as? How would you solve the specific problem of an
| evil ISP hijacking DNS?
|
| > centralized entity like Cloudflare (who, by every
| right, are precisely in a position to be an evil ISP)
|
| ISPs tend to have regional monopolies, but DoH servers
| don't. If Cloudflare becomes evil, you can just switch to
| some other DoH server.
|
| > If you care to learn, consider things without DoH: you
| can edit your hosts file. You can choose your DNS
| servers. You can run a local recursive resolving DNS
| server. You can block ads and advertisingware using your
| DNS server and/or something like Pihole. You can block
| all DNS queries to the outside world on your network so
| that they all go through your own resolvers.
|
| All but the last thing is still possible with DoH, and
| it's a good thing that it breaks the last thing, since
| doing that would affect other people's endpoints too.
|
| > Next, consider a world where DoH is commonplace: you
| have no control over DNS lookups on your own system.
|
| How do you figure? DoH is still configurable.
|
| > Your only choice is to not run binaries that might do
| things you don't like.
|
| I already don't.
|
| > Want to block ads or adware, or adult sites, or
| conspiracy sites, or any of a number of other things on
| the Windows system that your child uses? Now Edge doesn't
| let you. Want to block the Trojans and phishing sites
| that Google serves through their ad network? Chrome
| doesn't let you.
|
| Those are still easy: just point at a DoH server that
| does those blocks, the same way you'd point at an
| insecure DNS server that does them today.
|
| > You can block common DoH servers, until Cloudflare puts
| them on the same address as the endpoints for their
| millions of hosting customers. But what happens when apps
| do DoH lookups using random Amazon AWS or Google Cloud
| servers? How do you block them? Do you block ALL https?
|
| It's a good thing that network-level blocking of DoH is
| hard.
|
| > You see, you'd give up freedom, and have everyone else
| give up their freedom, for some abstract "safety" from
| ISPs that use your DNS data. You'd apply a shitty fix for
| 1% of the people to 100% of the people, rather than
| create tools for the 1% to circumvent their evil ISPs.
|
| What freedom am I giving up? What harm does DoH do to
| regular people?
| johnklos wrote:
| You're not arguing in good faith. You're suggesting that
| me controlling my own network, and people controlling
| their own networks, is bad ("even when you are the owner
| of a network, you shouldn't have control of traffic on it
| between endpoints that you don't own either of").
|
| You're suggesting that applications and Trojans have the
| "right" to be free from my control, on my network, on my
| machines. Wow. What a take!
|
| You're saying that all programs, Trojans included, will
| allow us to configure DoH. Again, a pretty crazy take,
| and completely, unambiguously wrong.
|
| "What freedom am I giving up? What harm does DoH do to
| regular people?"
|
| You clearly don't care about freedom, since you actively
| want to send your DNS to some third party. But you'd have
| me give up my freedom to control what goes on on my
| network because some ISPs track DNS, and instead of
| addressing that, you're for the idea of normalizing a
| protocol that removes my freedom and puts it in the hands
| of application / Trojan makers.
|
| It harms regular people because it exfiltrates private
| information that they don't know about. Someone installs
| Firefox (very common) and doesn't know about DoH (also
| very common). Now their DNS lookups are all going to
| Cloudflare. We have no reason to trust Cloudflare (we do
| have plenty of reasons to not trust them, though).
|
| But the point is that these regular people DON'T KNOW and
| haven't agreed to have their DNS data shared with
| Cloudflare. This has all sorts of negative implications
| that I'm sure you can't see.
| josephcsible wrote:
| > You're suggesting that me controlling my own network,
| and people controlling their own networks, is bad ("even
| when you are the owner of a network, you shouldn't have
| control of traffic on it between endpoints that you don't
| own either of").
|
| Should your ISP be allowed to censor what you can see on
| the Internet? Remember they own the network that all of
| your traffic flows through.
|
| > You're suggesting that applications and Trojans have
| the "right" to be free from my control, on my network, on
| my machines. Wow. What a take!
|
| I'm not arguing that anything on your machines should be
| free from your control. I'm specifically saying that
| traffic passing through your network but _not_ from or to
| one of your machines should be free from your control.
|
| > You're saying that all programs, Trojans included, will
| allow us to configure DoH. Again, a pretty crazy take,
| and completely, unambiguously wrong.
|
| I meant all legitimate programs do. Trojans obviously do
| whatever they want, and that was the case even before DoH
| existed.
|
| > You clearly don't care about freedom, since you
| actively want to send your DNS to some third party.
|
| You're always sending your DNS requests to some third
| parties. The only question is which.
|
| > But you'd have me give up my freedom to control what
| goes on on my network because some ISPs track DNS, and
| instead of addressing that, you're for the idea of
| normalizing a protocol that removes my freedom and puts
| it in the hands of application / Trojan makers.
|
| I disagree that "my freedom to control what goes on on my
| network" is a freedom that should be protected. For an
| extreme example, consider that someone complaining "they
| took away my freedom to own slaves" is obviously in the
| wrong. As I've said before, you should only have any
| control of traffic for which one of the endpoints is
| yours.
|
| > It harms regular people because it exfiltrates private
| information that they don't know about. Someone installs
| Firefox (very common) and doesn't know about DoH (also
| very common). Now their DNS lookups are all going to
| Cloudflare. We have no reason to trust Cloudflare (we do
| have plenty of reasons to not trust them, though).
|
| Most American ISPs are way less trustworthy than
| Cloudflare, and that's where almost everyone's DNS would
| be going otherwise.
|
| > But the point is that these regular people DON'T KNOW
| and haven't agreed to have their DNS data shared with
| Cloudflare. This has all sorts of negative implications
| that I'm sure you can't see.
|
| Do regular people even know what DNS is? Did they agree
| that their ISP could see their insecure DNS?
| johnklos wrote:
| I can't tell if you're a troll or if you're really just
| not understanding things.
|
| My network is not my ISP's network. My ISP can't censor
| me. I advocate for people to have control over their own
| networks and to take control from their ISPs.
|
| I'm not sure why you want to conflate my network with
| what my ISP provides, but anyone thinking that clearly
| doesn't understand how things work (or is just trying to
| be a troll).
|
| Likewise, "all legitimate" programs will allow DoH
| configuration? Really? Have you TRIED to do simple,
| common sense things in Windows like use another browser?
| Obviously this suggestion is ridiculous.
|
| Please tell me how traffic would pass through my network
| that isn't from or to one of my machines. Guests? That's
| a bullshit reason to suggest I shouldn't have control
| over my network.
|
| "You're always sending your DNS requests to some third
| parties." No, I'm not. I run my own DNSSEC recursive
| resolvers.
|
| At this point, I have to believe you're a troll.
|
| "consider that someone complaining "they took away my
| freedom to own slaves"" is also trolling. If you think
| packets and programs are equivalent to humans, you're...
| broken. But at this point I really have to wonder what
| you expect to get out of trolling. You're just making
| yourself look dumb at this point.
| josephcsible wrote:
| > My network is not my ISP's network.
|
| Right, but traffic from your computers passes through
| both.
|
| > My ISP can't censor me.
|
| Either you and your ISP can both do network-level
| censorship, or neither can.
|
| > I'm not sure why you want to conflate my network with
| what my ISP provides, but anyone thinking that clearly
| doesn't understand how things work (or is just trying to
| be a troll).
|
| Because your endpoints' traffic goes through both, and
| they both have the same ability to censor.
|
| > Likewise, "all legitimate" programs will allow DoH
| configuration? Really? Have you TRIED to do simple,
| common sense things in Windows like use another browser?
| Obviously this suggestion is ridiculous.
|
| Again, what does being able to change the default browser
| on Windows have to do with whether you can configure DoH?
|
| > Please tell me how traffic would pass through my
| network that isn't from or to one of my machines. Guests?
| That's a bullshit reason to suggest I shouldn't have
| control over my network.
|
| Guest computers on your network are in the exact same
| position as your router on your ISP's network.
|
| > "You're always sending your DNS requests to some third
| parties." No, I'm not. I run my own DNSSEC recursive
| resolvers.
|
| Even if you don't count the servers your recursive
| resolver talks to as third parties, your ISP can still
| see all of your recursive resolver's traffic, and just
| drop the responses for domains it doesn't want you
| visiting, even with DNSSEC.
|
| > "consider that someone complaining "they took away my
| freedom to own slaves"" is also trolling. If you think
| packets and programs are equivalent to humans, you're...
| broken.
|
| I don't think they're equivalent at all. My point was
| just that just because you can't do a certain thing
| anymore doesn't necessarily mean freedom has been lost.
| AnthonyMouse wrote:
| > Taking control away from the owner of networks is a
| good thing. Control is supposed to reside with the owner
| of _endpoints_. To see why, imagine if your ISP started
| to MITM all of your connections that went over their
| network.
|
| What you need for this is some kind of encrypted DNS.
| What you don't need is for it to be implemented in the
| way DoH commonly does it.
|
| What you should have is a router, which hands itself out
| as the DNS server via DHCP, takes the client's plaintext
| DNS request and does an encrypted query -- ideally
| directly to the authoritative servers for that domain,
| but at least to something of your choosing. Or, you
| configure your device to do this itself for every
| application using the system DNS. These all work fine,
| because the device owner can reasonably change them --
| you configure it in one place for every application or
| your whole LAN at once.
|
| The problem with DoH is that it puts it into each
| individual application, and then its infeasible for the
| device owner to change it because it's a million settings
| in a million places and some applications don't support
| changing it at all. Worse, you get evil _applications_
| where the endpoint device is the thing controlled by Evil
| Corp and the local network is the thing the device owner
| is using to block spyware. At which point "the network"
| needs to be able to block this or malware and evil IoS
| garbage can operate with impunity.
|
| The claimed workaround is that browsers try to resolve a
| particular name with the system DNS and then turn of DoH
| if it resolves in a particular way, but now you're back
| to this:
|
| > It's a case of "can't, because even if you change the
| setting, $evil_isp will hijack the queries anyway".
|
| Because then $evil_isp can just resolve that name in that
| way to go back to doing the MITM. At which point you've
| lost any benefit of the device doing this against a truly
| malicious ISP, or it becomes an excuse to remove this
| "feature" and then the device owner can't do it either.
|
| This is the wrong way to do it.
| josephcsible wrote:
| > browsers try to resolve a particular name with the
| system DNS and then turn of DoH if it resolves in a
| particular way
|
| I agree that's the wrong way to let DoH be turned off,
| exactly for the reason you describe. It should only be
| possible for DoH to be disabled by, e.g., the local user
| manually going into settings or by Group Policy.
|
| > What you should have is a router, which hands itself
| out as the DNS server via DHCP
|
| The problem with that is that I don't trust the DHCP
| server of whatever network I'm on to not be trying to
| censor or surveil me.
| AnthonyMouse wrote:
| > I agree that's the wrong way to let DoH be turned off,
| exactly for the reason you describe. It should only be
| possible for DoH to be disabled by, e.g., the local user
| manually going into settings or by Group Policy.
|
| DHCP _is_ group policy for network configuration. If you
| 're connecting to a network where you don't trust the
| DHCP server then don't use DHCP for DNS or use a VPN.
|
| > The problem with that is that I don't trust the DHCP
| server of whatever network I'm on to not be trying to
| censor or surveil me.
|
| The application default needs to be the system DNS and
| the device default needs to be DHCP so the device owner
| can feasibly change them. Then anyone for whom this
| doesn't work _can_ change it merely by changing one
| system-wide setting, with the easiest way being to use a
| VPN and their DNS -- something that should be done on
| untrusted networks regardless.
| josephcsible wrote:
| Nothing is wrong with DoH. When people complain about it,
| it's generally because they like being able to successfully
| perform the kind of attacks it's meant to prevent, e.g.,
| censorship and surveillance of traffic between endpoints
| they own neither of, just because the traffic passes
| through their network.
| nfoz wrote:
| Are you familiar with https://pi-hole.net/ ?
|
| In my house I want DNS resolution to be performed by my
| own DNS resolver (https://github.com/NLnetLabs/unbound),
| after I block ad domains.
|
| DoH circumvents that.
| EvanAnderson wrote:
| I agree with you, but the counterargument that'll be made
| against you is "you should be doing that on the
| endpoints".
|
| That counterargument ignores the fact that you can be the
| owner of an endpoint but not be permitted, by
| manufacturer's policy, to control the software running
| inside. That's what you get for purchasing a proprietary
| device.
|
| So, as the network operator and owner of the endpoints in
| the world of DoH (and pinned certificates), you end up
| being left with the decision to "vote with your wallet"
| and simply not purchase devices that don't afford you
| influence on name resolution (or whatever functionality
| we're talking about)
|
| The counterargument goes on to say that the manufacturers
| of these sealed-box devices can functionally do this
| today anyway simply by implementing their proprietary
| name resolution (content delivery, etc) protocol.
|
| It was all fun while it lasted.
| xorcist wrote:
| This is a power struggle, which I do not believe is really
| even on purpose by the people involved.
|
| We used to have a decentralised Internet with a truly open
| and engineering-led garden of interoperable protocols.
| However during the past decade and a half we've seen a
| massive change. We find ourselves in a situation where only
| https matters. It's a catch 22 type of situation, where
| anything else better be able to tunnel over it, otherwise
| many users will be left out since it's all that is
| supported, because it's what others tunnel over.
|
| While this happened, the browser organizations grew
| politically strong and now controls not only the public key
| infrastructure that underpins https but also
| standardization of https itself.
|
| The only exception to this is dns. Together with ip itself
| it follows the open meritocratic process that gave us
| decentralised planet wide internetworking. Unfortunately,
| it is closely tied with the domain name system, which is
| controlled by a parallel organization which isn't as open
| and meritocratic.
|
| So basically we have three stakeholders of political value
| in the Internet ecosystem today. Us proponents of open and
| permissionless internetworks closely align with one, one is
| a gray area, and one is a conglomerate of private
| companies.
|
| It is really healthy for the Internet if Mozilla, Microsoft
| and Cloudflare took control over dns resolving on a wide
| scale? Even apart from the obvious privacy issues?
|
| They may mean well, but it logically follows that when dns
| is centralized among a few actors, they also will have an
| unproportionally large say in the evolution of the system.
| They could even tack on some extra top domains or other
| extensions that they could resolve. All in good faith of
| course. But that would, in time, bring over any remaining
| users of the old decentralized system.
|
| It's not as if similar things hasn't happened before, in
| other contexts. So, yes, I will be one of the holdouts and
| keep resolving my own dns queries. It's not harder than
| "apt-get install unbound". It's the way the distributed
| domain name database was designed to work, and for good
| reason.
| josephcsible wrote:
| When you visit a site on Cloudflare today, both Cloudflare and
| your ISP see the domain name. With ECH, only Cloudflare will.
| folmar wrote:
| When I visit a more local website only my ISP and the site's
| ISP will see the domain name. With default browser setting
| some, probably overseas, entity that I didn't trust and
| didn't choose gets my request, ignoring my system
| configuration and without asking.
| supriyo-biswas wrote:
| I see a lot of confusion here, probably Cloudflare should have
| included an explanation of how ECH works in TFA instead of
| referring to their other article[1].
|
| The difference between ECH and SNI is that while SNI includes the
| hostname in the ClientHello (the first TLS record indicating
| connection initiation), ECH includes an encrypted section in the
| ClientHello called ClientHelloInner, and the hostname is moved
| inside it.
|
| The ClientHelloInner is encrypted using a public key made
| available over DNS, which is queried over DNS over HTTPS
| providers such as Google or Cloudflare DNS; plaintext DNS is
| avoided in order to prevent a MITM on the ClientHelloInner key.
|
| Doing so prevents ISPs and governments from analyzing your
| traffic. However, a CDN operator such as Cloudflare terminates
| TLS for your website, and thus traffic would be visible to them
| either way.
|
| Now, to the non-technical part of it: while ECH provides a
| significant privacy improvement, I personally am against its
| implementation. Most ISPs enforce country-specific orders to
| block domains using a combination of DNS packet interception and
| SNI inspection. The legitimacy or sanity of such laws are a
| separate matter - countries would want to block websites that
| violate their laws.
|
| If we take away this last resort from governments, they would
| react by enforcing client side blocklisting and DRMization as
| suggested in France[2], or force root certificate installation
| using legislation[3], or blocking large swathes of the internet
| as is the case with China.
|
| [1] https://blog.cloudflare.com/encrypted-client-hello/
|
| [2] https://www.article19.org/resources/france-proposed-
| internet...
|
| [3] https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-
| middle_a...
| silverwind wrote:
| Why is DNS required to encrypt a TLS handshake? Why are there
| two SNIs in a ClientHello?
|
| ECH seems like a overengineered implementation when they could
| just have released TLS 1.4 which encrypts that section of the
| handshake.
| stefan_ wrote:
| How do you "just encrypt it"? Encryption in TLS starts after
| you have verified who you are talking to via the certificate,
| otherwise you might just be doing encryption with whoever
| happens to MITM you. However to do the verification, the
| server must know what domain you are actually trying to reach
| - hence the SNI. This is why there is the DNS side channel.
| andrewaylett wrote:
| Bootstrapping the encryption is a problem: until you've run
| the handshake, you don't have a key with which you _could_
| encrypt the handshake. And you don 't want the key to live
| for too long, so folk _are_ going to end up trying to use
| expired keys.
|
| Between the article and the linked introduction, all of what
| you are looking for is explained.
| josephcsible wrote:
| > while ECH provides a significant privacy improvement, I
| personally am against its implementation. Most ISPs enforce
| country-specific orders to block domains using a combination of
| DNS packet interception and SNI inspection. The legitimacy or
| sanity of such laws are a separate matter - countries would
| want to block websites that violate their laws.
|
| That's exactly why I'm in favor of it: it makes effective
| censorship impossible.
|
| > If we take away this last resort from governments, they would
| react by enforcing client side blocklisting and DRMization as
| suggested in France[2], or force root certificate installation
| using legislation[3]
|
| Note that those plans both thankfully failed.
|
| > or blocking large swathes of the internet as is the case with
| China.
|
| No free country would tolerate that.
___________________________________________________________________
(page generated 2023-09-29 23:01 UTC)