[HN Gopher] Comcast, Mozilla strike privacy deal to encrypt DNS ...
___________________________________________________________________
Comcast, Mozilla strike privacy deal to encrypt DNS lookups in
Firefox
Author : trulyrandom
Score : 189 points
Date : 2020-06-25 13:33 UTC (9 hours ago)
(HTM) web link (arstechnica.com)
(TXT) w3m dump (arstechnica.com)
| WarOnPrivacy wrote:
| > Mozilla in November accused ISPs of lying to Congress in order
| to spread confusion about encrypted DNS. Mozilla's letter to
| Congress criticized Comcast
|
| > NCTA cable lobby that Comcast belongs to wrote a letter to
| Congress objecting to Google's plans for encrypted DNS. Comcast
| gave members of Congress a lobbying presentation that claimed the
| encrypted-DNS plan would "centraliz[e] a majority of worldwide
| DNS data with Google". Comcast's lobbying presentation also
| complained about Mozilla's plan for Firefox.
|
| Compromise, 2020 style: Comcast retains access to it's users DNS
| data and Mozilla doesn't dogpiled by NCTA-purchased legislators.
| CWuestefeld wrote:
| At home I've got a pihole handling my DNS, including using DoH to
| Cloudflare.
|
| I assume that this configuration is superior to whatever FF is
| doing natively, and I should disable FF's DoH support?
| apocalyptic0n3 wrote:
| If you do not disable Firefox's DoH support, it will by pass
| your Pi-Hole entirely. So you'd lose all the benefits of that
| and be limited to just the protections Firefox provides (which
| are great, to be clear. Just not as good as a well-sourced
| Pi0Hole)
| deeter72 wrote:
| This is why I absolutely despise DoH. SysAdmins have no
| direct control over it. In my organization we have blocked
| direct IP access from userspace VLAN's to all known public
| DNS servers thus forcing all clients to rely on the company
| DNS servers, which is not the most ideal way to do things.
| speedgoose wrote:
| Why do you want them to rely on the company DNS servers?
| jlgaddis wrote:
| 1. Internal names won't resolve if a client is using, for
| example, 1.1 as their DNS server (breaking, among other
| things, logging on to an Active Directory domain!)
|
| 2. Many companies have established DNS logging and
| monitoring in place for security.
| deeter72 wrote:
| Active Directory, Internal Domains, monitoring, blocking,
| etc.
| yjftsjthsd-h wrote:
| Don't you just set a canary domain -
| https://support.mozilla.org/en-US/kb/canary-domain-use-
| appli... - and then it's disabled for your network?
| deeter72 wrote:
| Again not the most ideal way to do things and Mozilla is
| doing a different approach to Chrome and Edge. and also a
| concern is that malware can use DoH to retrieve data
| without logging suspicious DNS queries on Firewall DNS
| logs which are monitored to highlight of new domains that
| have not been pre-approved.
|
| DNS should be something that is handled by the OS. I
| favor DoT which is secure and practical over DoH.
| jlgaddis wrote:
| Actually, in that case, adding the canary domain to your
| existing Microsoft DNS servers probably _IS_ the most
| ideal way to disable Firefox 's DoH support.
|
| Alternatively, you can roll out a Group Policy or use
| Mozilla's "Enterprise" policies to do it.
|
| Hopefully you're also blocking 53/TCP and 53/UDP outbound
| (except from your internal DNS servers).
| [deleted]
| jefftk wrote:
| _> malware can use DoH to retrieve data without logging
| suspicious DNS queries on Firewall DNS logs_
|
| Malware can already query IPs of its choice to learn
| about other IPs it should contact. DoH doesn't let it do
| anything new.
| jlgaddis wrote:
| In a corporate network, it's pretty common to block all
| outgoing DNS traffic (53/TCP and 53/UDP), except from the
| company's DNS servers.
|
| In that case, DoH _does_ let malware do something new --
| block the company 's existing DNS policies, quert
| logging, and security monitoring!
| jefftk wrote:
| DoH is a protocol for using HTTPS to learn what IPs to
| talk to.
|
| Malware does not need DoH to do this. They can simply run
| an ordinary HTTPS server with a self-signed cert on an
| arbitrary IP, with a simple JSON-based or whatever
| protocol, and have support for that in their client.
| jlgaddis wrote:
| > _Malware does not need DoH to do this._
|
| Yes, you're right, of course.
|
| There are any number of things that malware _can_ do.
| Most of it doesn 't, however, and can either be stopped
| completely or, at the least, detected quite easily using
| some basic techniques.
| DyslexicAtheist wrote:
| > and I should disable FF's DoH support?
|
| yeah there is no reason (I can think of) why you need FF DoH
| with your setup. In fact if you were to enable DoH in FF it
| would bypass your pie-hole - so you most certainly want to
| avoid that.
|
| my setup looks pretty much like yours with some additional
| /etc/hosts blocking[1] on the client just to avoid the round-
| trip to the pie-hole. it's also a double insulation (but it's
| more of a performance reason than bc of paranoia). I found that
| switching off ipv6 dns resolution in FF (
| _`network.dns.disableIPv6`_ in about:config) has tremendously
| sped up my DNS lookups in FF (though I haven 't had time to
| analyze why).
|
| in case you're worried about homograph phishing attacks you
| could also add a regex to your pie-hole's dnsmasq (not sure
| what piehole uses but I know it has a fork of dnsmask that
| supports regex) so that punicode domains (any domains matching
| "xn--") are sinkholed to 0.0.0.0 as well.
|
| [1] https://github.com/StevenBlack/hosts
| SAI_Peregrinus wrote:
| No need to disable Firefox's DoH support, just point it at your
| pihole as the DoH provider.
| pbhjpbhj wrote:
| How do you do that without accessing each client, like how do
| I disable DoH on my home network for all devices without
| having to access all devices?
| nfoz wrote:
| > "Adding ISPs in the TRR program paves the way for providing
| customers with the security of trusted DNS resolution, while also
| offering the benefits of a resolver provided by their ISP such as
| parental control services and better optimized, localized
| results," the announcement said.
|
| What? No! Why would DNS have "optimized, localized results"?
| bzbarsky wrote:
| Consider a hostname that can map to different, widely
| geographically separated, IPs. You probably want the one with
| the lowest latency, which is likely to be the closest-located
| one. Not guaranteed, of course.
| parliament32 wrote:
| You should just use anycast for that instead of trying to
| shoehorn it in with DNS trickery.
| sprayk wrote:
| It's interesting that the DNS-based solution is considered
| "trickery", when I don't really know anyone except for very
| networking-focused people who can explain how anycast works
| to achieve the same thing. While BGP is definitely not
| magic, it feels way more magic to me than DNS.
|
| The DNS-based solution, in comparison, seems way simpler to
| explain: get general location of IP of requester, send back
| the IP of a server in a DC closest to that location.
| jlivingood wrote:
| > Why would DNS have "optimized, localized results"?
|
| Any content that is CDN-based (which is most content)
| dynamically responds to DNS queries based on network and
| geographic location - to support CDN localization. In this way,
| Akamai for example knows the end user is in Boston on a Comcast
| network and will send the recursive DNS server a dynamic
| response that points to a directly-connected local-to-Boston
| content server.
| Eikon wrote:
| Any serious CDN is doing that with anycast, not with geodns
| which has tons of drawbacks.
| etrabroline wrote:
| You're right. This is really cool tech.
| https://www.cloudflare.com/learning/cdn/glossary/anycast-
| net...
| virtuallynathan wrote:
| That's not the case - many use hybrid approaches, and
| GeoDNS is still used heavily in the industry. Anycast sucks
| too.
| nfoz wrote:
| oh, I didn't know that. thanks!!
| kodablah wrote:
| How does FF know my DNS is a Comcast-provided one? Is there an IP
| list kept inside of browsers and updated?
| jlgaddis wrote:
| Comcast's ASNs and networks are documented in ARIN's WHOIS
| database and various route registries. Hell, Comcast probably
| publishes a list on their own web site.
|
| So, yeah, Mozilla can easily determine if a user is on the
| Comcast network just from their IP address.
|
| Also, while Comcast actually has a bunch of DNS servers spread
| across the country, I believe that nowadays they're mostly
| "promoting" the use of 75.75.75.75 and 75.75.76.76 (which,
| AFAIK, are anycasted and direct end users to their "local" DNS
| servers).
| kodablah wrote:
| > So, yeah, Mozilla can easily determine if a user is on the
| Comcast network just from their IP address.
|
| I mean, how can the determine it's a Comcast DNS server
| configured on my network? I might be a Comcast customer w/ a
| custom DNS server configured. If it's a fixed IP check, I
| suppose that list is in the browser.
| floatingatoll wrote:
| A draft RFC was published today:
| https://news.ycombinator.com/item?id=23644068
| CKN23-ARIN wrote:
| If you can run your own local, recursive resolver, you should.
| ruffrey wrote:
| Is this the same Comcast that:
|
| 1) created an RFC to inject JavaScript into non-TLS pages 2)
| created an RFC to intercept failed DNS lookups / connections with
| their own error page
|
| Both of which I reported to the FCC as MITM attacks. Comcast
| followed up referenced the bunk RFCs saying "it's fine."
| jlgaddis wrote:
| Let me make sure I've got this right:
|
| * Comcast sniffs / records / tracks their user's DNS traffic
|
| * Mozilla announced they would enable DoH by default, to protect
| end user's DNS data from shady ISPs like Comcast
|
| * Comcast then raised hell about Mozilla's decision (presumably
| because they would no longer have access to this data)
|
| * Now, Comcast and Mozilla come to some sort of agreement which
| effectively restores Comcast's access to their customer's DNS
| traffic?
|
| ---
|
| I'm really confused why Mozilla would agree to this. I _really_
| hope this isn 't one of the ways they're exploring to "diversify"
| their revenue streams but, in the last few years, Mozilla has
| made a lot of decisions that I don't agree with so I suppose I
| really wouldn't be all that surprised.
| Nextgrid wrote:
| I don't understand why Mozilla should care or get involved at
| all into what Comcast thinks of them.
|
| Mozilla introduce a privacy feature in a free, open-source
| browser. Comcast bitches about it because it prevents them from
| doing shenanigans, essentially incriminating themselves and
| proving that the feature is both working as expected and
| necessary.
|
| Why does Mozilla need to care about Comcast's opinion on this,
| and try to work out an "agreement" with them? It's equivalent
| to antivirus software actually working, and then the antivirus
| developer does a deal with the virus makers because the
| antivirus is actually effective and the virus makers are
| complaining.
|
| I am really disappointed in Mozilla's recent features, poor
| focus and nonsensical management.
| stefan_ wrote:
| This is the Mozilla we know. While touting their privacy
| record, they keep running head first into the biggest privacy
| debacles imaginable.
|
| Certifying an ISP that ran a NXDOMAIN hijack scheme while no
| doubt also selling DNS data for DoH is beyond the pale.
| heavyset_go wrote:
| > _I 'm really confused why Mozilla would agree to this._
|
| If it's anything like their CloudFlare deals, then Mozilla did
| this because they were able to secure contracts that provide
| additional privacy protections for Mozilla's customers that the
| parent company doesn't normally provide to end-users.
|
| In theory, those contracts should be enforceable in court.
| Whether or not you think the companies Mozilla contracts with
| will find ways to snoop on the private data anyway is a
| different story.
| pbhjpbhj wrote:
| Who are Mozilla's customers? Google are to a close
| approximation the only ones who pay them??
| detaro wrote:
| Also: People don't want Mozilla to send all DoH traffic to one
| company, so Mozilla has set a list of things they require a
| company to do so that they'll use their DoH servers
| automatically. Apparently, Comcast has agreed to said list.
| (We'll have to see if details on oversight and enforcement are
| published)
| jlivingood wrote:
| > Comcast sniffs / records / tracks their user's DNS traffic
|
| Actually not only does Comcast say they don't do that
| (https://www.xfinity.com/privacy/policy/dns) but now has signed
| a contract to this effect as well, thereby meeting the same
| level of commitment as the other TRR operators. This means IMO
| that Mozilla is doing a good job leading the industry on DNS
| privacy and convincing many of the merits of a strong pro-
| privacy philosophy.
|
| (disclosure: I work for Comcast and have been working on
| encrypted DNS)
| elliekelly wrote:
| That's great that they've said they don't publicly and that
| they're now going to be contractually obligated not to... but
| that's kind of irrelevant if they are actually sniffing,
| tracking, and/or recording user DNS traffic.
|
| And the fact that Comcast doesn't allow users to change the
| DNS settings of xfinity routers leads me to believe they have
| _some_ monetary incentive to go in and disable that
| functionality in their equipment.
| LeifCarrotson wrote:
| It is entirely possible for one group (or incentive) within
| Comcast's organization to work towards that goal, and another
| group or incentive within Comcast to work against it.
|
| _Some things that make me trust this claim:_
|
| - That privacy policy
|
| - That contract
|
| - Association with trustworthy brands like Mozilla
|
| - Work on encrypted DNS
|
| - Consumer trust could theoretically be financially valuable
| to them
|
| - Basic morals of Comcast employees
|
| _Some things that make me distrust it:_
|
| - Cultivated an infamous litany of consumer abuses
|
| - Lobbied for regulations to harm consumers
|
| - Engaged in regulatory capture with the FTC/FCC
|
| - Have continually profited from their abusive business
| practices, and continue to profit in spite of atrocious
| levels of consumer trust
|
| I believe that Comcast only wants to respect user privacy
| insofar as it helps them maintain a facade of trustworthiness
| and retain customers. If they ever get the opportunity to
| back out of that privacy-conscious posturing and turn it into
| money, I think history has proven that the winner of those
| two internal groups is clearly going to be the money side not
| the moral side.
| xxpor wrote:
| The link provided only concerns logging of DNS requests on
| Comcast's DNS servers themselves. It doesn't say anything
| about recording packets to UDP port 53 in general. If Comcast
| were recording every packet I sent to 8.8.8.8 they wouldn't
| be breaking the letter of the policy.
| booi wrote:
| Hopefully this is exactly what DoH should be addressing.
| pbhjpbhj wrote:
| Given your disclosure presumably you know if it's true or
| not.
|
| It's a weird way to phrase "I work on this, we don't capture
| any information about customers site visits" or "I work on
| this we don't capture any information about domain lookups"
| or whatever.
|
| When a customer gets a contract with Comcast are you saying
| the contract includes that Comcast will not filter/log their
| domain lookups in any way?
|
| To others: what's the penalty of they breech that contract?
| Do they actual have anything at risk?
|
| In UK ISPs couldn't make such a contract as the gov obliges
| DNS filtering of some domains, AIUI.
| tialaramex wrote:
| UK ISPs could offer to operate a Mozilla TRR DoH server for
| two reasons:
|
| 1. The deal major "as seen on TV" ISPs struck was that they
| would offer a configurable child protection style filtering
| to their users. Mozilla permits users to _opt in_ to
| filtering, you just aren 't allowed to filter by default,
| so an ISP provided DoH server which _can_ be configured
| explicitly to filter would meet this requirement. NextDNS
| offers this, yet is in Mozilla 's programme. If you just
| pick NextDNS from the drop-down in Firefox you get no
| filtering, if you sign up and pay them (or take the free
| offer) you get filtering of your choice, and DoH, with
| instructions on how to tell your Firefox about this
| (basically paste a per-user URL into a preferences window,
| the nice thing about DoH compared to plain DNS or even DoT
| is that in a URL your user identifier will be encrypted,
| improving privacy)
|
| 2. The government _did not_ legislate a requirement. They
| 've been burned before on the difference between public
| appeals to think of the children (generally broadly
| accepted by the populace, no legal fallout) and censorship
| laws (likely to be destroyed in the courts because it turns
| out people don't like being told what to read). All those
| famous ISPs chose to voluntarily censor the Internet
| (mustn't let kids see porn) and then since they had the
| capability to censor courts told them to also obey
| Hollywood's instructions (no Pirate Bay either).
|
| A small ISP like Andrews & Arnold isn't censored. During
| sign-up it says "Do you need child friendly filtering as
| part of this product?" or something. If you click "Yes" it
| says sorry they don't want you as a customer, good bye and
| the sign-up process is over.
| pwdisswordfish2 wrote:
| Can users enforce that contract if it is breached? Maybe
| users should be named explicitly as third party
| beneficiaries.
|
| Mozilla is a company and needs to compensate its CEO and
| staff. The CEO received $2,458,350 in 2018.^1 Everything
| Mozilla does cannot be solely for users' benefit. Mozilla,
| the people behind it, have their own financial interests.
|
| 1. https://assets.mozilla.net/annualreport/2018/mozilla-2018-
| fo...
| hellcow wrote:
| Respectfully, Comcast has an ATROCIOUS privacy record. Full
| stop. A quick search came up with [1] [2] [3].
|
| Your employer actively and repeatedly abuses the privacy and
| trust of its customers. It also lobbies for damaging
| policies.
|
| I do not trust Comcast. Firefox associating itself with
| Comcast makes me trust Firefox significantly less.
|
| [1] https://oag.ca.gov/news/press-releases/attorney-general-
| kama...
|
| [2] https://www.king5.com/article/news/local/comcast-
| fined-9-mil...
|
| [3] https://consumerist.com/2016/04/01/comcast-says-fcc-
| privacy-...
| Paul-ish wrote:
| If Comcast sells DNS data now, they open themselves up to
| penalties from the both FTC and Mozilla. FTC because they
| enforce privacy policies, and Mozilla because of the contract
| they have.
|
| I would say this Mozilla changing the overall ecosystem for
| the better.
| jlgaddis wrote:
| Do we know what the actual penalties are? I have trouble
| believing that they are of any substance.
|
| Additionally, I think it's safe to say that Comcast has
| years and years of experience in finding "loopholes" and/or
| other "workarounds" in its agreements.
|
| > _I would say this Mozilla changing the overall ecosystem
| for the better._
|
| You obviously have much more faith in Comcast than I do.
| Let's hope you're right.
| Forbo wrote:
| > _Do we know what the actual penalties are? I have
| trouble believing that they are of any substance._
|
| So long as the penalty is less than the value they derive
| from violating the agreement, they will abuse it.
| gsich wrote:
| No. And Mozilla can't verify it either.
| elliekelly wrote:
| The FTC has no teeth and no one at Comcast is losing any
| sleep over potential FTC penalties. Ajit Pai is more likely
| encourage meaningful enforcement of this agreement than
| anyone at the FTC. Which is to say, I don't have much
| faith.
| catalogia wrote:
| What good is a contract between Mozilla and Comcast to me
| if Mozilla is unwilling to notice/care/sue when Comcast
| breaks that contract because Mozilla has a financial
| incentive to turn a blind eye?
| luma wrote:
| Comcast has had a pretty poor track record w/r/t their
| statements of what they do or don't do versus reality, and
| this goes back well over a decade (see: denials of Sandvine
| deployment).
|
| I personally was impacted by this behavior after having my
| internet service deactivated due to going over bandwidth caps
| (which reportedly didn't yet exist) and it was one of the
| most Kafka-esque corporate experiences in my life. My
| internet was being deactivated because I violated a policy
| which they repeatedly stated didn't exist. Several months
| later those caps actually became policy.
|
| I ask this with all sincerity: why should we believe Comcast?
| jlgaddis wrote:
| > _Actually not only does Comcast say they don 't do that..._
|
| Just like they said they didn't forcibly reset BitTorrent
| connections (until they did).
|
| Just like they said they didn't silently institute bandwidth
| caps (until they did).
|
| Just like they said they didn't hijack NXDOMAIN responses
| (until they did).
|
| Just like they said they didn't intercept plain-text HTTP
| connections and inject their own traffic into them (until
| they did).
|
| ---
|
| With all due respect, I have personally had contracts with
| Comcast in the past and have experienced firsthand how well
| they honor those -- and I am certainly not the only one!
|
| Surely you can understand why, to me and many others, their
| little agreement with Mozilla doesn't really mean a damn
| thing?
|
| ---
|
| (I know that none of this is _your_ fault and it 's obviously
| nothing personal! I'm sure you're a smart, decent person but
| I'm also sure that you are well aware of your employer's
| reputation, their past "misdeeds", and, of course, the
| generally unfavorable opinion that many, many customers have
| of them.)
| virtuallynathan wrote:
| After the NXDomain redirection stuff, they invested a ton
| in doing DNS right, deploying DNSSEC and Anycast. They are
| a major participant in the IETF, DNS OARC, and many other
| industry working groups, if you attend these things, go
| talk to the Comcast folks!
|
| Their limited use of HTTP interception is a published RFC,
| and I've thought about ways to get around this, and for the
| use cases they use it for, it seems like the only viable
| option.
|
| I knew a few of folks who were involved in the BT RST
| thing, the whole org learned a lot from that, and internal
| opinions changed.
| roblabla wrote:
| > With all due respect, I have personally had contracts
| with Comcast in the past and have experienced firsthand how
| well they honor those -- and I am certainly not the only
| one!
|
| Consumer contracts? Because Mozilla having a business
| contract with Comcast is certainly not the same as you
| having a consumer contract - Mozilla has the resources to
| drag Comcast to court should they be found to ignore the
| agreement.
| pwdisswordfish2 wrote:
| When pigs fly!
|
| Can you imagine Mozilla CEO depleting her own
| compensation in order to sue a company the size of
| Comcast? What exactly are the claimed damages in this
| hypothetical lawsuit? The damages to Mozilla are _____ ?
| (This PR piece in Ars suggests the deal is solely to
| protect users. No financial details.) How about the
| damages suffered by users? (Whoops, they are not parties
| to the agreement.)
|
| Quite the vivid imagination!
|
| Maybe the "white knight" narrative really does work on
| some people.
| pbhjpbhj wrote:
| Where can we read the contract?
| nerdponx wrote:
| This is a wildly bad take in my opinion.
|
| Comcast has proven themselves to be uninterested in
| adhering to their contractual obligations. You bet your
| ass they are 1) figuring out how to work around their
| contract with Mozilla without attracting legal attention,
| and 2) making contingency plans for winning any resulting
| lawsuit.
| gsich wrote:
| >Now, Comcast and Mozilla come to some sort of agreement which
| effectively restores Comcast's access to their customer's DNS
| traffic?
|
| They could (and can) do that regardless of DNS. Most websites
| and other services are uniquely identifiable by their
| IP(-range).
|
| Encrypted SNI is still a draft so not applicable here.
| causality0 wrote:
| It would also be a good idea to split your encrypted DNS
| lookups between as many providers as possible so as to both
| minimize its value to any one entity and also minimize the
| amount of data a single bad-faith provider would get.
| nimbius wrote:
| welp, thats it lads. DoH was a fun experiment until Mozilla
| decided to let the fox back into the henhouse. You can be damn
| sure "the foundation" got a nice fat cheque for their hard work
| letting predatory surveillance capitalism continue unfettered.
| yarrel wrote:
| Mozilla loves partnerships. They don't have to be revenue
| streams. They just preferably have to be hostile to user
| freedom.
|
| Mozilla needs to fix the internal incentives that lead to this
| situation.
| noncoml wrote:
| I don't know how we can have privacy and Comcast in one sentence.
| We have a saying where I come from that translates roughly to
| "Putting the Wolf to Guard the Sheep".
|
| If you don't have any other option but to be with comcast my
| recommendation is to run Pi-Hole + DoH.
| city41 wrote:
| I do run PiHole. Any tips on how to do the `DoH` side of the
| equation?
|
| edit: this looks to do the trick: https://docs.pi-
| hole.net/guides/dns-over-https/
| noncoml wrote:
| Sorry, just saw the reply. Yes, cloudflared is what I do at
| the moment.
| danShumway wrote:
| This is a net increase in privacy for most people on Comcast
| networks, I'm glad to see Mozilla striking a deal like this --
| especially with the privacy agreements Comcast is signing. _But_
| you should still switch your encrypted DNS provider to someone
| else like Cloudflare or similar.
|
| In short, good move, but you personally can make better moves
| than trusting Comcast.
| Washuu wrote:
| Considering that Comcast sniffs, intercepts, and injects into
| HTTP web sites for their customer notification system(data cap
| overages and such) this just screams suspicious to me even if it
| seems like it is meant to be a good announcement. I am not sure
| how I am supposed to trust that they will do the right thing for
| their customers.
| proverbialbunny wrote:
| I hit commit on that feature. Sorry.
|
| It's not just Comcast. Every ISP that uses Akamai's software to
| power their ISP has this ability and possibly uses it, just not
| in obvious ways. And given that almost every ISP in the US, let
| alone the world, uses this software, well.. that's just how it
| is.
|
| Though, it's http only. You can always switch to https and they
| can not do anything. There is no key injection or anything
| going on thankfully. Also, encrypted DNS should make it moot as
| well.
| sprayk wrote:
| How would encrypting DNS help me avoid Comcast MITMing my
| HTTP traffic to inject bandwidth cap notifications? Doesn't
| the system just inject a script tag into the appropriate
| place in the HTTP response?
| entropicdrifter wrote:
| HTTPS Everywhere + encrypted DNS blocks a huge chunk of
| what they can see without expending effort on _you in
| particular_
| sprayk wrote:
| that is not what I was asking. GP claimed that encrypted
| DNS would stop comcast from injecting notifications into
| _HTTP_ traffic, I want to know how that would work, in
| the hopes that my assumptions about the system are wrong.
| proverbialbunny wrote:
| You make a good point. I worked on the code before
| encrypted DNS was a thing (or anything I knew about) so
| I'm going off of theory, not first hand experience.
|
| When a request is sent for a http web page it is ran
| through the layer 4 proxy. In there is a user profile
| where http injection can occur. It works by injecting
| JavaScript into the end of the web page.
|
| If the dns request is encrypted it should in theory
| bypass the layer 4 proxy. However, it could be that as
| years have gone by it's been updated to take in http data
| without a domain name being sent to an IP and then it
| would work again.
|
| So, me in my half awake state this morning didn't really
| think it through. In previous versions of the software
| this wouldn't be supported, but in hindsight it's
| somewhat trivial a problem to fix, so Comcast probably
| does support HTTP injection even when using encrypted
| DNS. My apologies.
| chaostheory wrote:
| I also wonder what the RIAA and MPAA think of this? I know
| using a browser isn't ideal for piracy, but at the same time
| those two organizations are one of several major reasons why
| ISPs snoop on their customers.
| sprayk wrote:
| does RIAA/MPAA snooping rely on DNS traffic at all? I was
| under the impression that the only thing RIAA/MPAA caught
| people for was the act of sharing, usually in the form of
| torrent seeding, and this was done by third parties they
| contracted out to who would provide a list of IPs they caught
| seeding. Then the list of IPs were resolved to ISPs who were
| sent subpoenas where they thought they had a good chance of
| ISP cooperation. Is there some legal, warrantless wiretapping
| I'm not aware of?
| MINIMAN10000 wrote:
| I don't care what their intent is. Interception and injection
| from a third party is bad.
|
| With technology there are many ways to achieve the goal of
| notifying a customer without foul play.
| threw23434 wrote:
| > Considering that Comcast sniffs, intercepts, and injects into
| HTTP web sites
|
| You think that is bad ? If you get a connection from India's
| 'premier' public telco BSNL, you'll be treated to ad-injections
| for random malware straight into your HTTP page.
|
| "Your govt. welcomes your appreciation for its 'top-notch'
| services."
| NelsonMinar wrote:
| I'm very suspicious of Comcast too. They've had hostile
| policies in their Internet management for as long as I can
| remember, going back to the days they'd forge RST packets
| because they didn't like customers using BitTorrent.
|
| OTOH as the article says, 'Joining Mozilla's program means that
| Comcast agreed that it won't "retain, sell, or transfer to any
| third party (except as may be required by law) any personal
| information, IP addresses, or other user identifiers, or user
| query patterns from the DNS queries sent from the Firefox
| browser'.
|
| I assume Mozilla will audit and keep Comcast honest here, or at
| least try. I just am left wondering what loophole Comcast has
| found.
| csharptwdec19 wrote:
| >I assume Mozilla will audit and keep Comcast honest here, or
| at least try. I just am left wondering what loophole Comcast
| has found.
|
| HAHAHAHAHAHA OH YOU ARE FUNNY.
|
| Sorry.
|
| Comcast will use the same loophole they use with everyone
| else. Kafkaesque policies aren't just for their customers,
| they exist throughout the organization.
|
| Took me 6 months to get a Secure VPN link that -they-
| insisted we use to set up their files. And 3 months of that
| was just getting the password reset. The account was locked
| because it wasn't being used (first 3 months was them
| fighting with firewall configs)...
|
| But then we were in this loop of they would reset the
| password, but the person who had to TELL us the password was
| reset would take so long to do so that it expired again by
| the time we got it.
|
| So, extrapolating to here, my guess is that any sort of audit
| will take forever to get data, probably incomplete sets...
| you get the picture.
| sandworm101 wrote:
| There is nothing that Comcast can do that would increase my
| opinion of them re privacy. In my security regime ISPs like
| them are on the other side. Last-mile ISPs are unsecured public
| networks that shouldn't be trusted any more than free airport
| wifi. I want them blind to everything I (and my client) does
| online. Encrypt everything. Route DNS to trusted non-profit
| entities. Serve me the encrypted data I request but otherwise I
| don't want to even have a conversation with Comcast.
| Skunkleton wrote:
| > Route DNS to trusted non-profit entities.
|
| I'm sure you know this, but some readers might not. DNS is
| totally insecure. Even if you change your DNS server from the
| default to 1.1.1.1 or whatever, your ISP can and does still
| read and/or intercept these requests. This sort of
| interference is absolutely trivial to implement, even at
| scale. Don't think it isn't happening to you.
| sandworm101 wrote:
| >> Even if you change your DNS server from the default to
| 1.1.1.1 or whatever, your ISP can and does still read
| and/or intercept these requests.
|
| Not if VPNs/firewalls are properly implmented. Plugging DNS
| leaks is security 101.
| treve wrote:
| I get that VPNs are considered more trustworthy by some
| (although so many also have shoddy records/ownership),
| but it's still 1 extra party to trust vs. just your DNS
| provider.
| solarkraft wrote:
| ... which is exactly why DoH is gaining attention.
|
| But I keep wondering: Can't the ISP trivially correlate the
| accessed IP addresses with their corresponding sites even
| without DNS query data?
| ethbro wrote:
| Trivial in the individual case is not trivial at scale.
| SAI_Peregrinus wrote:
| Only for sites with dedicated IPs. If they're hosted on
| some sort of cloud service then the ISP has to sniff the
| SNI data. And with ESNI coming to encrypt it that hole
| will be plugged soon.
| the8472 wrote:
| That just means moving from the ISP in a prime position
| for snooping to various CDNs being in that prime
| position.
|
| You traded one master for another.
| xoa wrote:
| > _You traded one master for another._
|
| No. By definition, last mile ISP sees 100% of net-bound
| traffic. "Various CDNs" itself already represents a
| dilution of that view, and are not universal themselves.
| It's an inherent improvement even outside of other
| factors. But there are other factors, including a
| decrease in the level of natural monopoly. Last-mile ISPs
| often have zero effective competition, and even with one
| or two there are often high change over costs, longer
| term contracts involved, etc. The closer you get to the
| net's core however, the more bandwidth there is and the
| more players there are and in turn vastly more
| competition potential. That's not a guarantee sure, but
| it absolutely makes a difference. There's also a limiting
| factor principle at work: even if you do trust a given
| ISP, how does that help you avoid CDNs anyway?
|
| It's the same reason that spinning up your own instance
| of an algo VPN on some VPS and funneling all your home
| and mobile traffic through that may have practical
| benefits. Sure in principle the VPS (or data center if
| you go on your own metal) provider could try spying as
| well. But competition there is fierce, the average
| technical level of users is higher, major business
| interests are involved in reputation, and swapping to
| another provider is utterly trivial. The incentives and
| business models for the likes of Amazon/DigitalOcean/Goog
| le/Microsoft/OVH/Scaleway/Vultr/[...] in their compute
| offerings are completely different from the likes of
| AT&T/Charter/Comcast/T-mobile/Verizon. So it is in fact
| reasonable to expect a difference in the level of
| shenanigans too, and hey, if not you can easily move,
| which _also_ in turn makes it much easier as a practical
| matter to retaliate (sue), which virtuously further
| decreases the likelihood of shenanigans.
| the8472 wrote:
| You have a contractual relation with your ISP and they're
| in your jurisdiction so at least in theory you have legal
| recourse.
|
| Advocating for ESNI on the other hand means argueing for
| more centralization towards entities which are far more
| removed from you where you have little recourse. So as
| far as incentives go they may be more beholden to some
| law enforcement agency than you the non-customer.
|
| There are difference, but it does not appear to be an
| obvious improvement to me.
| judge2020 wrote:
| Let's try the one that hasn't eagerly and willingly (that
| we know of) gone against their users.
| the8472 wrote:
| That heavily depends on who those parties are. E.g. a
| european might trust their local ISP (subject to GDPR)
| more than an american CDN (subject to the cloud act and
| NSLs).
| grishka wrote:
| Also don't forget about SNI. This exposes the domain
| you're connecting to over TLS. Yes, I know eSNI is a
| thing, but it's new and so unlikely to be deployed much.
| tmikaeld wrote:
| Agreed, if it was cloudflare I would have at least given them
| the benefits of a doubt, but not Comcast.
| rydre wrote:
| Cloudflare is harmful to independent CDN's. They hide the
| originating i.p. address (no other does it) to the nameserver
| in the name of "privacy" so you can only have as much
| granularity as the nearest cloudflare server to user (anti-
| competitive). That is unless you buy an ipv4 block (because
| everyone is still on ipv4) and set up anycast.
|
| For non 1.1.1.1 dns users I can just set up varnish and
| they'll be served via GEO ip lookup so the domain gets
| pointed to the nearest ip address. This is much cheaper. I'm
| not going to buy an ipv4 block just for cloudflare dns users.
|
| Their privacy claim is a lie because your webserver is going
| to be exposed to the end user i.p. address anyways after
| resolving from the nameserver.
| tssva wrote:
| Not forwarding EDNS client subnet is a requirement for
| Mozilla TRR partners. NextDNS also doesn't forward EDNS
| subnet client since it is a partner and soon Comcast will
| be joining that list. Although not currently a member of
| the program Quad9 also by default doesn't forward EDNS
| subnet info.
| rydre wrote:
| I host my name server's myself. If Mozilla is really
| doing this, they're misguided. All this does is make it
| impossible to serve requests from nearest webserver. You
| are getting the ip address anyways, so why do this? This
| means if I get someone from netherlands I'd have to
| redirect their requests from www.example.com to
| nl.example.com or buy an ipv4 block, set up anycast and
| then serve from the closest ipaddress/server. The end
| result is same. I'll always get the end user's ip address
| unless they use a VPN or something.
|
| This is a stupid decision by Mozilla. Too bad Firefox
| users when visiting websites making their own CDN's
| without anycast/country level redirects will see much
| slower sites.
| ViViDboarder wrote:
| You will always get the IP because you host the
| nameserver and the web server. In many cases, the
| nameserver is hosted by a third party. Doesn't what
| Mozilla and Cloudflare have done prevent the nameserver
| from receiving the originating IP, thus preventing large
| nameservers from generating user traffic histories? This
| is an honest question. I'm not fully familiar with the
| process of running a nameserver.
| presumably wrote:
| What you're claiming is false.
|
| Cloudflare has over 200 PoPs; in your own name servers,
| you can use the Cloudflare Resolver's IP (which will be a
| "close to the user" IP, not 1.1.1.1) to do geotargeting
| and serve from your closest IP address/server.
| rydre wrote:
| >What you're claiming is false. Cloudflare has over 200
| PoPs; in your own name servers, you can use the
| Cloudflare Resolver's IP (which will be a "close to the
| user" IP, not 1.1.1.1) to do geotargeting and serve from
| your closest IP address/server.
|
| What if my server is closer than cloudflare? Why is
| cloudflare artificially limiting?
| willcipriano wrote:
| I use cloudflare precisely because I don't want clients
| hitting the server directly. That's its entire purpose.
| For both caching and anti-ddos reasons.
| sprayk wrote:
| rydre is specifically talking about the perspective of
| someone running a non-cloudflare CDN or possibly a site
| that does their own CDN with DNS rather than anycast
| because they explicitly don't want to use cloudflare for
| whatever reason. They are not talking about someone just
| hosting a site.
| DoctorOW wrote:
| EDIT: I associated the name Cloudflare with the main
| product. I forgot the context of this being about DNS and
| therefore my comment is about Cloudflare CDN not 1.1.1.1
|
| > Cloudflare is harmful to independent CDN's.
|
| Cloudflare is a competitor to CDNs. You don't need to use a
| CDN with Cloudflare, they proxy your content fully and do
| caching along the way as needed.
|
| > Their privacy claim is a lie because your webserver is
| going to be exposed to the end user i.p. address anyways
| after resolving from the nameserver.
|
| It's not a lie. Cloudflare is the nameserver, and the CDN.
| So after resolution the end user still has just a
| Cloudflare IP.
| rydre wrote:
| > _It 's not a lie. Cloudflare is the nameserver, and the
| CDN. So after resolution the end user still has just a
| Cloudflare IP._
|
| > _In 2011 Google wrote an IETF draft to send Client IP
| information using the EDNS0 extension and this is usually
| called 'edns-client-subnet'. As a DNS client, it means
| that a truncated version of your IP address will be added
| into the DNS request. The DNS server will use this
| truncated IP address to make a more informed decision in
| how it responds so that you can be connected to the most
| optimal server. This standard is promoted by the Faster
| Internet initiative and already adopted by some leading
| vendors.
|
| Because it is designed to keep privacy, the sender has
| the freedom to limit the client IP information. Instead
| of sending a full IP address, the DNS server is able to
| send partial information such as /24 only. For instance,
| if your IP address is 66.214.81.22, the DNS server will
| only expose the first three octets, so 66-214-81. Armed
| with the real IP address of the querying device, the DNS
| server can now come up with a much more accurate
| response. With this more intelligent routing, customers
| have a better Internet experience with lower latency and
| faster speeds. Best of all, this integration is being
| done using an open standard that is available for any
| company to integrate into their own platform._
|
| source: https://engineering.salesforce.com/why-is-edns-
| important-for...
|
| Cloudflare 1.1.1.1 for consumers kills EDNS "edns-client-
| subnet" and instead offers the ip of the nearest
| cloudflare server to the user even if the website is not
| using cloudflare. This means your website can not ever
| serve content faster then cloudflare _even_ if you could
| potentially be faster.
|
| This is the reason why many internet archives do not
| allow access to cloudflare client dns (1.1.1.1) users as
| a form of protest.
|
| BTW, Cloudflare allows you to get informed about the end
| user's ip via a "x-forwarded-for" header.
| presumably wrote:
| There is only a single "archive" that does not allow
| access to Cloudflare DNS users - not many.
|
| It is also exceedingly unlikely that you have greater
| density of anycast PoPs than Cloudflare's 200+. In your
| case, you have zero...
| Fej wrote:
| Even archive.today has given up on that crusade; I
| noticed a few days ago that they don't block me anymore
| (I use Cloudflare DNS) so they have to have stopped
| within the past couple weeks.
|
| So now AFAIK the number of sites that block DNS resolvers
| which do not forward edns-client-subnet is zero. As it
| should be.
| miyuru wrote:
| Akamai has more than 200 pops and do geodns to stear
| traffic.
|
| If I compare cloudflare DNS vs Google DNS, I can see a
| difference of ~50ms between the Akamai POPs offered.
|
| https://pastebin.com/raw/xFQb4pVF
| [deleted]
| zaroth wrote:
| I think you're confusing how CloudFlare can hide the
| _server_ IP from the user (to protect against DDoS)
| versus how CloudFlare DNS hides the _client's IP_ from
| the name server, even though the Client IP is exposed to
| the web server by Cloudflare, and of course standard
| Cloudflare is irrelevant if the requested site isn't
| using the Cloudflare service in the first place.
| surround wrote:
| I've never understood the purpose of DOH. It doesn't really hide
| your traffic from any party, does it?
| floatingatoll wrote:
| It encrypts your DNS traffic over the public wire in a way that
| only the DOH endpoint operator can decrypt, preventing
| plaintext interception/modification attacks by unauthorized
| malicious actors positioned between you and the DOH endpoint
|
| It represents your DNS traffic over the wire as encrypted HTTPS
| traffic, which decreases the effectiveness of deep packet
| inspection and traffic shaping systems operated by some network
| providers.
|
| When hosted at heavily-used CDN endpoints that receive other
| (non-DOH) HTTPS traffic, it requires a network provider who
| wishes for whatever reason to block your DNS traffic to block
| all HTTPS traffic to all CDN endpoints.
| bosswipe wrote:
| Weird that a network or OS level concern is being moved to the
| application layer. But considering that trust in all the other
| layers has been lost, from the ISP to the OS (specifically
| Windows), maybe this makes sense.
| jbverschoor wrote:
| The whole newroling stack needs encryption etc. This is one
| reason why you see everything moving of the layers. The other
| is, that Http servers are widely available, tested and easily
| scalable
| yarrel wrote:
| Headline announces opposite of what has happened.
| ohnope wrote:
| I'm confused. For me, a major selling point of DoH is it hides
| DNS queries from your ISP, which has detailed personal
| information about you. And if you're locked into Comcast, you're
| operating with completely eroded trust from the get-go.
|
| Clearly, DNS statistics are extremely valuable to Comcast, or
| they would not have engaged with Mozilla to get back the data,
| nor would they have raised hell with Congress.
|
| I would not have expected an organization like Mozilla to sign a
| data deal with Comcast, even if Comcast is now theoretically
| restricted on how they use the data.
|
| This is a weak move.
| bad_user wrote:
| Mozilla cannot enable one provider by default. People already
| complained that Cloudflare was initially the only choice.
|
| Users at the moment are expected to choose their provider
| anyway.
|
| This deal is about Mozilla picking Comcast by default for
| Comcast customers. This is essentially as if they'd be using
| the network's default, because Comcast is the network's default
| already. They can always choose a different provider.
| gruez wrote:
| >Comcast told Ars yesterday that "Firefox users on Xfinity should
| automatically default to Xfinity resolvers under Mozilla's
| Trusted Recursive Resolver program, unless they have manually
| chosen a different resolver, or if DoH is disabled.
|
| How would this work? Is the detection done once, everytime
| firefox starts, or everytime the network changes? Would you ever
| get into a situation where you're not using comcast, but are
| still using comcast dns? eg. you have VPN enabled or your laptop
| moved to somewhere else.
|
| >Joining Mozilla's program means that Comcast agreed that it
| won't "retain, sell, or transfer to any third party (except as
| may be required by law) any personal information, IP addresses,
| or other user identifiers, or user query patterns from the DNS
| queries sent from the Firefox browser," along with other
| requirements.
|
| And how is this enforced? If comcast breaches the agreement, is
| anyone going to sue them for punitive damages? Given the current
| state of the US legal system (eg. what happened equifax after the
| breach), these assurances are worthless to me.
| ta576248_743568 wrote:
| My understanding is that Comcast signs a legally-binding
| contract with Mozilla which imposes the requirements on them
| [0]. This obviously isn't perfect protection, but it
| substantially increases the risk of failing to adhere to the
| requirements. Mozilla claims "We intend to publicly document
| violations of this Policy and take additional actions if
| necessary." [1]. Presumably the additional actions include
| suing for damages pursuant to the breach of contract.
|
| [0] https://blog.mozilla.org/netpolicy/2020/02/25/the-facts-
| mozi... [1] https://wiki.mozilla.org/Security/DOH-resolver-
| policy#Enforc...
| pbhjpbhj wrote:
| Surely damages will be approximately zero? There has to be
| something else to sway Comcast's executives to abide by the
| contract, surely. Like the CEO agrees to forfeit an amount
| equal to their previous years total earnings, from all
| sources, ... that would be an interesting contract!
| jlivingood wrote:
| > How would this work?
|
| A 1st draft of the steering mechanism just posted today for
| comment at https://tools.ietf.org/id/draft-rescorla-doh-
| cdisco-00.txt
| stx wrote:
| So Mozilla wanted encrypted DNS Comcast did not. Now they made a
| deal. Comcast agreed in writing not to monitor DNS. So what did
| Mozilla give up to make this deal? Mozilla wont encrypt DNS on
| Comcast connections? Something does not add up.
| saltedonion wrote:
| Why can't mozilla roll out a encrypted dns service in a form of a
| browser setting or plugin? Does the browser not have control over
| how the dns is resolved ?
| tofaz wrote:
| Would be Comcast able to intercept the TLS SNI requests anyway
| and see at least were the traffic is directed?
___________________________________________________________________
(page generated 2020-06-25 23:00 UTC)