281–290 of 777 posts
Earlier quoted context omitted.
You can sort of assume anybody paying any attention to traffic is sniffing the SNI information, it's pretty obvious.
Not all ISPs around the world have the resources to do that. It also doesn't have to be 100%, we just have to make it difficult (or more expensive) and that helps.
Earlier quoted context omitted.
It's actually quite massive. Most sites (well not most, but a lot) sit behind something like cloudflare, so your scummy intercepting ISP would only see a connection to cloudflare. Of course none of this really means too much until encrypted SNI is a thing but it's a definitely a lot more than marginal imo
You can sort of assume anybody paying any attention to traffic is sniffing the SNI information, it's pretty obvious.
So hopefully not a cause that's lost forever, but we can improve more in the future.
Does anyone know when something like this might come to Brave?
I know Brave is supposed to be a privacy-centric browser, but their plan for advertising seems at odds with that. Advertising is a slippery slope and I wonder how long before these promises are eroded or outright reversed. > 100% of your ad spend is placed for active users that opt-in to a rewarding private ad experience. > Craft effective offers and provide captivating full-page experiences directly with consumers i…
The same thing you saw happen to any other cryptocurrency. It basically kills all earnest conversation.
The Brave thought this was worthwhile makes the whole thing feel scummy to me. But we are way off topic.
Earlier quoted context omitted.
And now they have a one-stop shop for all their DNS surveillance needs.
> And now they have a one-stop shop for all their DNS surveillance needs. There are a few dozens of DoH services out there [1] and nothing prevents anybody else from running their own. [1] https://github.com/curl/curl/wiki/DNS-over-HTTPS
Earlier quoted context omitted.
Chrome uses opportunistic DoT - it uses your system configured resolver, and if it supports DoT, it will use DoT, if not, it will fall back to 53/udp. I like Chrome's approach much better; it doesn't force you to statically configure DNS server - it is a PITA, especially when roamining and you want to resolve hostnames available only in local networks.
> ...it is a PITA, especially when roamining and you want to resolve hostnames available only in local networks. Not really. If you're not blackholing traffic at the dns-layer via DoH, set Firefox's trr.mode to 2 . Per documentation, at the cost of additional latency incurred, system-level / network-level resolvers should pick up the slack, provided they've been set as appropriate via DHCP or otherwise. Ref: https://…
This "We know better than you" attitude is why I stopped using Firefox so many years ago. I switched back recently, to stop using Chromium, but I have a growing list of annoyances, and it might be time to give NeXt Browser a chance again, or see what else is out there.
Earlier quoted context omitted.
What are some reasons why someone would prefer to or need to disable it. Just curious.
I'm not sure if disabling it is the right way to go, but I do not plan on letting Firefox ship all my DNS queries to CloudFlare. I do not trust Cloudflare any more (and maybe a little less honestly) than my ISP. I do want a container with my own DNS-over-HTTP running on my own hosted VM (or Digital Ocean, or Vultr or Linode or whoever) and I'll ship my DNS queries there.
You might also be interested in looking at https://dnsdist.org/guides/dns-over-https.html
Firefox DoH is snake oil, plain and simple. It sends all the users DNS queries to Cloudflare, adding a new party which can surveil the user's traffic (and can be legally compelled to do so and not disclose this fact)-- providing a convenient choke point to save spies and hackers the trouble and exposure of extracting the data from tens of thousands of individual ISPs.
Simultaneously, it does not protect the user from monitoring by their ISP or parties situated there because the user's destination IPs remain unencrypted, as well as the hostnames via SNI (for cases of shared hosting, e.g. on cloudflare, where the IP alone wouldn't be enough).
At the moment you can disable this across your whole lan by blocking traffic to 104.16.248.249, 104.16.249.249, 2606:4700::6810:f8f9, and 2606:4700::6810:f9f9 and by DNS blackholing use-application-dns.net and cloudflare-dns.com.
iptables -t raw -A PREROUTING -d 104.16.248.249 -j DROP
iptables -t raw -A PREROUTING -d 104.16.249.249 -j DROP
ip6tables -t raw -A PREROUTING -d 2606:4700::6810:f8f9 -j DROP
ip6tables -t raw -A PREROUTING -d 2606:4700::6810:f9f9 -j DROP
And if you're using bind:
zone "use-application-dns.net" { type master; file "/etc/bind/db.empty"; };
zone "cloudflare-dns.com" { type master; file "/etc/bind/db.empty"; };
Or unbound:
local-zone: "use-application-dns.net" static
local-zone: "cloudflare-dns.com" static
But there is no guarantee that these mitigations will continue to work.
[Edit: Aside, this comment and many/most(?) comments on this thread were moved from a more recent thread with a headline "Firefox turns on DoH as default for US users". The new title which omits the on-as-default, is kinda burying the lead.]
I don't have a Facebook account but with Firefox TRR, 'google.com' is the only address that resolves just fine — so I search Google (or directly from the address bar) for a website, click through to the result, and the ensuing session is allowed. Rinse and repeat for each new tab.
Any direct attempt to browse otherwise (including to google.com with other browsers) always hits the FB captive portal.