Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com
On Wed, 5 Jan 2022 19:42:33 +0100 wrote: > On Wed, Jan 05, 2022 at 12:41:23PM -0500, Celejar wrote: > > [...] > > > The configuration I'm talking about is as follows: the browser makes > > ordinary, unencrypted DNS requests to the Pi-hole, over a trusted > > network > > If the browser decides to make the DNS requests over HTTPS (DoH [1], > that's what we are talking about), the DNS server in your Pi-hole doesn't > even get to see those requests. So tell the browser not to use DoH! Am I really being so unclear? My point is that it's a straightforward matter to get the DNS requests of your applications - browsers, and all other applications as well - checked against blocklists, and then sent over DoH if they aren't blocked by the lists. > > (your LAN, or a VPN). HTTPS isn't necessary here insofar as you > > trust your own network to be secure. (And if you're really worried about > > intruders [...] > > No, no. I'm not worried about those things. I'm worried that the > browsers do their own thing to do name lookup so they escape my control > (be it via /etc/hosts, be it via an own DNS server, local or Pi-hole). I'm not sure why you're worried about browsers doing their own things despite your telling them not to, or where anyone mentioned such a concern in this thread, but if you are worried about that sort of thing, then I agree that it's pretty much game over. Even if you block known DoH servers at the firewall, I suppose you can always worry about browsers contacting some unknown DoH server. And why stop there? Maybe the browser will do some nefarious phoning home, using some homegrown protocol, encapsulated inside HTTPS so you'll never know about it! The bottom line is that yes, if you don't trust your browser and you allow it to contact arbitrary sites over HTTPS, then it's game over. > > https://www.reddit.com/r/pihole/comments/ku0i8k/configuring_dnsoverhttps_on_pihole/ > > Again: I'm not that much concerned about my lookup's privacy. The > Pi-hole having an option to do DoH lookups is fine. But do I trust my > browser to not do direct DoH lookups all by itself, bypassing my Pi-hole > (or whatever I've set up as a controlled DNS)? What about its next > version? Celejar
Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com
On Wed, Jan 05, 2022 at 12:41:23PM -0500, Celejar wrote: [...] > The configuration I'm talking about is as follows: the browser makes > ordinary, unencrypted DNS requests to the Pi-hole, over a trusted > network If the browser decides to make the DNS requests over HTTPS (DoH [1], that's what we are talking about), the DNS server in your Pi-hole doesn't even get to see those requests. > (your LAN, or a VPN). HTTPS isn't necessary here insofar as you > trust your own network to be secure. (And if you're really worried about > intruders [...] No, no. I'm not worried about those things. I'm worried that the browsers do their own thing to do name lookup so they escape my control (be it via /etc/hosts, be it via an own DNS server, local or Pi-hole). > https://www.reddit.com/r/pihole/comments/ku0i8k/configuring_dnsoverhttps_on_pihole/ Again: I'm not that much concerned about my lookup's privacy. The Pi-hole having an option to do DoH lookups is fine. But do I trust my browser to not do direct DoH lookups all by itself, bypassing my Pi-hole (or whatever I've set up as a controlled DNS)? What about its next version? Cheers [1] Browser folks have decided that making DNS requests over HTTP(S) is much more secure than over the "traditional" avenue. In a way, they are right. In another they are horribly wrong- https://en.wikipedia.org/wiki/DNS_over_HTTPS -- t signature.asc Description: PGP signature
Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com
On Wed, 5 Jan 2022 18:20:23 +0100 wrote: > On Wed, Jan 05, 2022 at 08:43:23AM -0500, Celejar wrote: > > On Wed, 5 Jan 2022 06:10:48 +0100 > > wrote: > > > > > On Tue, Jan 04, 2022 at 04:05:11PM -0500, Celejar wrote: > > > > > > [...] > > > > > > > One way "to combine DoH with resolving 14,000 addresses to 127.0.0.1" > > > > is by using Pi-hole. Some people have *millions* of domains blacklisted > > > > in Pi-hole: > > > > > > Pi-hole won't help unles it also does HTTPS proxying (that means it > > > would have to play MITM). As far as I know it "just" does conventional > > > DNS proxying (which is a great thing to do, mind you). > > > > Why won't it help? What won't it help with? > > (See also Dan's response: it seems that a compliant DoH client first > sends a local DNS request first, so you might have a handle through > this) > > With this caveat: how would you intercept a DNS request over HTTPS if > not by proxying HTTPS traffic? And that is exactly what MITM means. The configuration I'm talking about is as follows: the browser makes ordinary, unencrypted DNS requests to the Pi-hole, over a trusted network (your LAN, or a VPN). HTTPS isn't necessary here insofar as you trust your own network to be secure. (And if you're really worried about intruders and sniffers inside your network, you can always run Pi-hole on the same system as the browser itself (possibly in a container or VM), although that'll require dedicating some resources to the Pi-hole installation.) The Pi-hole then either blocks the request (if the address is on its blocklists), or looks it up via DoH. See, e.g., here: https://www.reddit.com/r/pihole/comments/ku0i8k/configuring_dnsoverhttps_on_pihole/ Celejar
Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com
On Wed, Jan 05, 2022 at 08:43:23AM -0500, Celejar wrote: > On Wed, 5 Jan 2022 06:10:48 +0100 > wrote: > > > On Tue, Jan 04, 2022 at 04:05:11PM -0500, Celejar wrote: > > > > [...] > > > > > One way "to combine DoH with resolving 14,000 addresses to 127.0.0.1" > > > is by using Pi-hole. Some people have *millions* of domains blacklisted > > > in Pi-hole: > > > > Pi-hole won't help unles it also does HTTPS proxying (that means it > > would have to play MITM). As far as I know it "just" does conventional > > DNS proxying (which is a great thing to do, mind you). > > Why won't it help? What won't it help with? (See also Dan's response: it seems that a compliant DoH client first sends a local DNS request first, so you might have a handle through this) With this caveat: how would you intercept a DNS request over HTTPS if not by proxying HTTPS traffic? And that is exactly what MITM means. Cheers -- t signature.asc Description: PGP signature
Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com
On Wed, 5 Jan 2022 06:10:48 +0100 wrote: > On Tue, Jan 04, 2022 at 04:05:11PM -0500, Celejar wrote: > > [...] > > > One way "to combine DoH with resolving 14,000 addresses to 127.0.0.1" > > is by using Pi-hole. Some people have *millions* of domains blacklisted > > in Pi-hole: > > Pi-hole won't help unles it also does HTTPS proxying (that means it > would have to play MITM). As far as I know it "just" does conventional > DNS proxying (which is a great thing to do, mind you). Why won't it help? What won't it help with? If you mean that the queries won't be secure during the leg between the client and the Pi-hole, we're talking about running Pi-hole within one's trusted network (or connecting to it over a VPN, etc.) > > But hey, full HTTP(S) proxying would be a great thing to do. Still, > you'd have to munge your browser's trusted certs for that trick to work. Celejar
Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com
to...@tuxteam.de wrote:
> On Tue, Jan 04, 2022 at 04:09:42PM -0500, Dan Ritter wrote:
>
> [...]
>
> > Here's what I do:
> >
> > My local DNS resolver offers DNS, DNS over TLS, and DNS over
> > HTTPS.
> >
> > I supply a use-application-dns.net zone that returns NXDOMAIN.
> > That tells browsers to not use DoH.
>
> Oh, is it possible to tell the browsers which host to ask to resolve DoH
> requests? That would be... nice :)
Not precisely which host. A compliant DoH client (FF, Chrome) is supposed to
start by asking local DNS for a record from
use-application-dns.net, which Mozilla runs. If your DNS server has
use-application-dns.net and insists on returning NXDOMAIN, then
the client should fall back to using whatever DNS the operating
system supplies.
In Bullseye, unbound has support for both DNS-over-TLS and
DNS-over-HTTPS -- the latter is new.
> > I build an adblocker zone [...] that always answers with a 204 [...]
>
> nice
Pick an IP in your local net - let's say, 10.0.0.254. Use that
as your DNS response instead of 127.0.0.1. This will work just
fine in /etc/hosts.
Make sure you have a machine listening to 10.0.0.254, and set up
a web server to answer regardless of name.
For nginx:
server {
listen 10.0.0.254:80;
server_name _;
root /var/www/blank;
index blank.png;
rewrite .+?(png|gif|jpe?g)$ /blankimg last;
rewrite ^(.*)$ / last;
location / {
return 204;
}
location /blankimg {
empty_gif; # See
http://nginx.org/en/docs/http/ngx_http_empty_gif_module.html
}
}
So if the page asks for an image, I supply a 1x1 transparent dot.
If it asks for anything else, 204, which is not an error.
-dsr-
Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com
On Tue, Jan 04, 2022 at 04:09:42PM -0500, Dan Ritter wrote: [...] > Here's what I do: > > My local DNS resolver offers DNS, DNS over TLS, and DNS over > HTTPS. > > I supply a use-application-dns.net zone that returns NXDOMAIN. > That tells browsers to not use DoH. Oh, is it possible to tell the browsers which host to ask to resolve DoH requests? That would be... nice :) > I build an adblocker zone [...] that always answers with a 204 [...] nice Thanks -- t signature.asc Description: PGP signature
Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com
On Tue, Jan 04, 2022 at 04:05:11PM -0500, Celejar wrote: [...] > One way "to combine DoH with resolving 14,000 addresses to 127.0.0.1" > is by using Pi-hole. Some people have *millions* of domains blacklisted > in Pi-hole: Pi-hole won't help unles it also does HTTPS proxying (that means it would have to play MITM). As far as I know it "just" does conventional DNS proxying (which is a great thing to do, mind you). But hey, full HTTP(S) proxying would be a great thing to do. Still, you'd have to munge your browser's trusted certs for that trick to work. Cheers -- t signature.asc Description: PGP signature
Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com
David Wright wrote: > On Tue 04 Jan 2022 at 19:37:34 (+0100), to...@tuxteam.de wrote: > > On Tue, Jan 04, 2022 at 01:19:37PM -0500, Michael Stone wrote: > > > > [...] > > > > > And this is why putting stuff into /etc/hosts is basically never the right > > > answer. :) > > > > Eye, beholder and things. I've got a couple of them like so: > > > > # Pest: > > 127.0.0.1 www.google-analytics.com > > 127.0.0.1 ajax.google.com > > 127.0.0.1 ad.doublecklick.net > > 127.0.0.1 www.gstatic.com > > ... > > > > Yeah, some things stop working then. I want them to :) > > Agreed. I append a list of close to 14,000 addresses (including > comments) to the end of my own local /etc/hosts. I see very > few adverts. In fact, I was quite shocked when I just tried > DNS over HTTPS for a couple of minutes. The 10-day weather > profile that I screenshoot every day was plastered in popups. > > Anyone know how to combine DoH with resolving 14,000 addresses > to 127.0.0.1? Also, does that mean that DoH attempts to resolve > my local hosts before consulting /etc/hosts? I didn't stick > around DoH long enough to find out. Here's what I do: My local DNS resolver offers DNS, DNS over TLS, and DNS over HTTPS. I supply a use-application-dns.net zone that returns NXDOMAIN. That tells browsers to not use DoH. I build an adblocker zone via a script that grabs several public lists, and those all return an address that is answered by a web server that always answers with a 204 (No Content, success). That's where you get to put your 14,000 addresses. The adblocker zone gets rebuilt when I feel like it; otherwise, I could put in a cron job to update it once a month or so. -dsr-
Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com
On Tue, 4 Jan 2022 20:58:27 +0100 wrote: > On Tue, Jan 04, 2022 at 01:33:18PM -0600, David Wright wrote: > > On Tue 04 Jan 2022 at 19:37:34 (+0100), to...@tuxteam.de wrote: > > > On Tue, Jan 04, 2022 at 01:19:37PM -0500, Michael Stone wrote: > > > > > > [...] > > > > > > > And this is why putting stuff into /etc/hosts is basically never the > > > > right > > > > answer. :) > > > > > > Eye, beholder and things. I've got a couple of them like so: > > > > > > # Pest: > > > 127.0.0.1 www.google-analytics.com > > > 127.0.0.1 ajax.google.com > > > 127.0.0.1 ad.doublecklick.net > > > 127.0.0.1 www.gstatic.com > > > ... > > > > > > Yeah, some things stop working then. I want them to :) > > > > Agreed. I append a list of close to 14,000 addresses (including > > comments) to the end of my own local /etc/hosts. I see very > > few adverts. In fact, I was quite shocked when I just tried > > DNS over HTTPS for a couple of minutes. The 10-day weather > > profile that I screenshoot every day was plastered in popups. > > > > Anyone know how to combine DoH with resolving 14,000 addresses > > to 127.0.0.1? Also, does that mean that DoH attempts to resolve > > my local hosts before consulting /etc/hosts? I didn't stick > > around DoH long enough to find out. > > No idea. I'd hope for it to be overridable, but I've been disappointed > by browsers (yes, firefox, I'm looking at you!) before. One way "to combine DoH with resolving 14,000 addresses to 127.0.0.1" is by using Pi-hole. Some people have *millions* of domains blacklisted in Pi-hole: https://www.reddit.com/r/pihole/comments/rrcmfk/why_am_i_making_a_personal_commitment_to_donating/ https://www.reddit.com/r/pihole/comments/7rzdzj/how_many_domains_do_you_have_on_your_setup/ https://www.reddit.com/r/pihole/comments/hkfyu4/domains_on_blocklist/ etc. and using DoH with Pi-hole is well documented: https://docs.pi-hole.net/guides/dns/cloudflared/ https://medium.com/codex/pi-hole-and-doh-f1a9f8acd0f7 https://github.com/devopsleigh/pihole Celejar
Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com
On Tue, Jan 04, 2022 at 10:34:48AM -0800, James H. H. Lampert wrote: On 1/4/22 10:19 AM, Michael Stone wrote: And this is why putting stuff into /etc/hosts is basically never the right answer. :) Au contraire! Among other things, the host table is the best possible place to block access to certain unwanted domains Not really, but it certainly is something that people do.
Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com
On Tue, Jan 04, 2022 at 01:33:18PM -0600, David Wright wrote: > On Tue 04 Jan 2022 at 19:37:34 (+0100), to...@tuxteam.de wrote: > > On Tue, Jan 04, 2022 at 01:19:37PM -0500, Michael Stone wrote: > > > > [...] > > > > > And this is why putting stuff into /etc/hosts is basically never the right > > > answer. :) > > > > Eye, beholder and things. I've got a couple of them like so: > > > > # Pest: > > 127.0.0.1 www.google-analytics.com > > 127.0.0.1 ajax.google.com > > 127.0.0.1 ad.doublecklick.net > > 127.0.0.1 www.gstatic.com > > ... > > > > Yeah, some things stop working then. I want them to :) > > Agreed. I append a list of close to 14,000 addresses (including > comments) to the end of my own local /etc/hosts. I see very > few adverts. In fact, I was quite shocked when I just tried > DNS over HTTPS for a couple of minutes. The 10-day weather > profile that I screenshoot every day was plastered in popups. > > Anyone know how to combine DoH with resolving 14,000 addresses > to 127.0.0.1? Also, does that mean that DoH attempts to resolve > my local hosts before consulting /etc/hosts? I didn't stick > around DoH long enough to find out. No idea. I'd hope for it to be overridable, but I've been disappointed by browsers (yes, firefox, I'm looking at you!) before. The day it ain't a choice anymore will be the day I hide behind a proxy *I* trust and control. That one can then look up things in /etc/hosts. (Yes, that means some bricolage with trusted root CAs. So be it.) Cheers -- t signature.asc Description: PGP signature
Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com
On 1/4/22 11:33 AM, David Wright wrote: In fact, I was quite shocked when I just tried DNS over HTTPS for a couple of minutes. The 10-day weather profile that I screenshoot every day was plastered in popups. Anyone know how to combine DoH with resolving 14,000 addresses to 127.0.0.1? Also, does that mean that DoH attempts to resolve my local hosts before consulting /etc/hosts? I didn't stick around DoH long enough to find out. Yeef! Thoughts of the Homer Simpson catchphrase, and the boss adversary from Arkanoid (and its sequel, Revenge of DOH), come to mind. -- JHHL
Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com
On Tue 04 Jan 2022 at 19:37:34 (+0100), to...@tuxteam.de wrote: > On Tue, Jan 04, 2022 at 01:19:37PM -0500, Michael Stone wrote: > > [...] > > > And this is why putting stuff into /etc/hosts is basically never the right > > answer. :) > > Eye, beholder and things. I've got a couple of them like so: > > # Pest: > 127.0.0.1 www.google-analytics.com > 127.0.0.1 ajax.google.com > 127.0.0.1 ad.doublecklick.net > 127.0.0.1 www.gstatic.com > ... > > Yeah, some things stop working then. I want them to :) Agreed. I append a list of close to 14,000 addresses (including comments) to the end of my own local /etc/hosts. I see very few adverts. In fact, I was quite shocked when I just tried DNS over HTTPS for a couple of minutes. The 10-day weather profile that I screenshoot every day was plastered in popups. Anyone know how to combine DoH with resolving 14,000 addresses to 127.0.0.1? Also, does that mean that DoH attempts to resolve my local hosts before consulting /etc/hosts? I didn't stick around DoH long enough to find out. Cheers, David.
Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com
On Tue, Jan 04, 2022 at 10:34:48AM -0800, James H. H. Lampert wrote: > On 1/4/22 10:19 AM, Michael Stone wrote: > > And this is why putting stuff into /etc/hosts is basically never the > > right answer. :) > > Au contraire! > > Among other things, the host table is the best possible place to block > access to certain unwanted domains. For example, if you add these entries: > > > 0.0.0.0 facebook.com [...] Oh, great minds think alike :) I put them to 127.0.0.1, because then I can see them hitting the wall in my local web server logs ;-) Cheers -- t signature.asc Description: PGP signature
Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com
On Tue, Jan 04, 2022 at 01:19:37PM -0500, Michael Stone wrote: [...] > And this is why putting stuff into /etc/hosts is basically never the right > answer. :) Eye, beholder and things. I've got a couple of them like so: # Pest: 127.0.0.1 www.google-analytics.com 127.0.0.1 ajax.google.com 127.0.0.1 ad.doublecklick.net 127.0.0.1 www.gstatic.com ... Yeah, some things stop working then. I want them to :) Cheers -- t signature.asc Description: PGP signature
Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com
On 1/4/22 10:19 AM, Michael Stone wrote: And this is why putting stuff into /etc/hosts is basically never the right answer. :) Au contraire! Among other things, the host table is the best possible place to block access to certain unwanted domains. For example, if you add these entries: > 0.0.0.0 facebook.com > 0.0.0.0 www.facebook.com > 0.0.0.0 hi-in.facebook.com > 0.0.0.0 gl-es.facebook.com > 0.0.0.0 twitter.com > 0.0.0.0 www.twitter.com you can never be tricked into accessing Facebook or Twitter (for me, ONCE is far too many times), and if you add > 0.0.0.0 bing.com then bing-redirections will fail every time (and alert you to their noisome and all-too-common presence). And likewise, you might want to access other machines within your LAN by name, but your operation is not big enough to warrant bothering with an internal DNS, or you might need to access outside systems that, for various perfectly legitimate reasons, are kept off the public DNS. -- JHHL
Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com
On Tue, Jan 04, 2022 at 01:09:06AM +0100, local10 wrote: Jan 3, 2022, 23:08 by d...@randomstring.org: Alright. Put this into your /etc/hosts temporarily: [...] OK, I understand now what the problem was. Quite a while ago I added a line into the /etc/hosts to fix a temp DNS issue and completely forgot about it. So while DNS server was correctly resolving tools.usps.com to 152.195.33.23, my previous /etc/hosts entry was overriding it to 23.217.162.158 which was causing the certificate issue. And this is why putting stuff into /etc/hosts is basically never the right answer. :)
Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com
On Tue, Jan 04, 2022 at 12:50:39PM +0100, local10 wrote: > Jan 4, 2022, 05:58 by to...@tuxteam.de: > > > Seems to work for me (currently). Are you still getting the error? > > > > > Not anymore, it has been solved: > https://lists.debian.org/debian-user/2022/01/msg00096.html > > Thanks to everyone who responded. Thanks, yes, I fllowed the thread :) Cheers -- t signature.asc Description: PGP signature
[SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com
Jan 4, 2022, 05:58 by to...@tuxteam.de: > Seems to work for me (currently). Are you still getting the error? > Not anymore, it has been solved: https://lists.debian.org/debian-user/2022/01/msg00096.html Thanks to everyone who responded.
[SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com
Jan 3, 2022, 23:53 by loca...@tutanota.com: > Jan 3, 2022, 23:08 by d...@randomstring.org: > >> Alright. Put this into your /etc/hosts temporarily: >> >> 152.195.33.23 www.usps.com tools.usps.com www.usps.gov >> >> That's unlikely to be an optimal IP from their CDN, but it is >> currently working. >> > > That fixed it, I got the USPS tracking page to load normally. Still not sure > why it worked as tools.usps.com resolves for me to 152.195.33.23: > > # dig tools.usps.com > ... > > ;; ANSWER SECTION: > tools.usps.com. 42 IN CNAME cs1799.wpc.upsiloncdn.net. > cs1799.wpc.upsiloncdn.net. 2078 IN A 152.195.33.23 > OK, I understand now what the problem was. Quite a while ago I added a line into the /etc/hosts to fix a temp DNS issue and completely forgot about it. So while DNS server was correctly resolving tools.usps.com to 152.195.33.23, my previous /etc/hosts entry was overriding it to 23.217.162.158 which was causing the certificate issue. Thanks to everyone who responded.
