Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com
On Wed, 5 Jan 2022 18:20:23 +0100
<tomas@tuxteam.de> wrote:
> On Wed, Jan 05, 2022 at 08:43:23AM -0500, Celejar wrote:
> > On Wed, 5 Jan 2022 06:10:48 +0100
> > <tomas@tuxteam.de> 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
Reply to: