Your connection is not private

[netboy]

I have "pfBlockerNG" enabled.

I used the "same" search criteria both in "chrome" and "brave" browser.

In the chrome browser when I click on the results I get "Your connection is not private" and unable to view the url linked web page, however the brave browser has no such problem (I am using google as my search engine in brave and chrome).

I would like to understand why the behavior's is different in chrome vs brave?

login-to-view

The brave browser has this option
login-to-view

[johnpoz]

@netboy because in one your using pfsense for dns, and your blocking that - and its sending you to the block page, which your browser doesn't trust the cert..

In the other browser your prob using doh, and not using pfsense for dns - so its not blocked.

[netboy]

@johnpoz said in Your connection is not private:

In the other browser your prob using doh, and not using pfsense for dns - so its not blocked.

All traffic goes thru router (pfsense) - Why is brave behaving differently?

[johnpoz]

@netboy said in Your connection is not private:

Why is brave behaving differently?

Because its not using pfsense for its dns.. Being routed through pfsense is not the same as asking it for dns..

When you query www.googleadservices.com - pfblocker is blocking it, and sending you to an IP on pfsense, the pfblocker block page.

When your other browser looks that up its not asking pfsense..

https://community.brave.com/t/how-to-enable-dns-over-https-doh/91769

if you disable doh in brave - it would do the same thing..

[netboy]

@johnpoz Thanks for the explanation.

For the benefit of others here is the current config in brave:

login-to-view

My next question is....

[1] pfBlockerNG is not allowing googleservices to get "in-between" my search URL - Which is kind of preventing google to gets stats from my search - Am I right?

[2] Brave browser uses cloudfare for DNS instead of my router using doh (DNS over HTTPS) - Am I right in my understanding.

[3] Brave approach using cloudfare is actually good because google now cannot interfere and study my search - Have I understood this correct? - In other words this is good for protection?

[4] google is the best in search. If pfBlockerNG blocks googleservices (assuming I use chrome) then what good it is to me? How do people use pfBlockerNG with chrome without getting "Your connection is blocked" message - is there a way to get best of both worlds?

[Gertjan]

@netboy

1. You use pfBlockerng with a DNSBL that lists "googleadservices.com" in one of its feeds, your Chrome browser use the DNS that your device got when obtaining a DHCP lease, and this lease says "the DNS is pfSense". Thus pfblockerng 'sees' this DNS request, finds it in the list, and sends "10.0.0.1" back. This 10.0.0.1 points to the pfBlockerng local web server that wants to you that the DNS request was blocked.
   But Chrome was waiting for a web site that says, with its certificate, that is is "googleadservices.com". That was not the case : pfBlockerng 's web server was answering, you get a warning.
   pfBlockerng can not make, create, and send a certificate that says 'I am googleadservices.com'. That's what "https" (TLS) is all about.

2. The Brave browser opens a encrypted (TLS, like https) channel through pfSense to a DNS server. Not pfSense, but somewhere on the Internet : cloudflare. pfSense can not 'see' thus intercept this data stream, which hides a DNS request.
   This is what TLS is all about.

3. It boils down to to : cloudflare is (uses) a resolver. pfSense has a resolver also. They both do the same thing. Who do you trust ? What do you want ?

4. Open for debate, but Google can be considered as a good search engine. Web site owners and Google itself uses "googleadservices.com" for the simple reason they want to harvest serach requests, so they can "help you better", and also collect stats, with the final end goal : to monetize your requests. As Google has also bills to pay.

How do people use pfBlockerNG with chrome without getting "Your connection is blocked" message - is there a way to get best of both worlds?

No real solution. It's a questions of choices and tradeoffs. Even if you would find the best solution, you've got thousands of Google's engineers making your live 'harder'. They want you to see these "adds", they want to know how you use their search engine.
If there was a perfect solution : No more income for Google. That means no more Google shortly after that.

[netboy]

@Gertjan Thanks for the detailed explanation.

"If I use brave I do not need pfBlockNG because brave stops advertisements + blocks googlservices to collect info - The benefit as I see it is that brave uses google search engine without affecting privacy"

I really do not need pfBlockNG if I use brave - Is my understanding correct? or I am missing something?

[Gertjan]

@netboy

I'm not a Brave user, can't tell.
What is 'better' depends on your usage.

[Bob.Dig]

@netboy said in Your connection is not private:

I really do not need pfBlockNG if I use brave - Is my understanding correct? or I am missing something?

I would use both anyway because the DNS sink-holing can do more for you than you might think. For me it is blocking stuff outside of my browser like other software or stuff on my phone phoning home etc.

[netboy]

@Bob-Dig said in Your connection is not private:

I would use both anyway because the DNS sink-holing can do more for you than you might think. For me it is blocking stuff outside of my browser like other software or stuff on my phone phoning home etc.

Thanks - this makes sense.

I wiould welcome others how they leverage google search and use various browsers. Basically I am looking for "best practise" how to leverage both google search (without privacy concerns) + pfBlockNG

[totowentsouth]

@netboy My best practices:

• qwant.com for search
• Firefox with uBlock origin and most of the default recommended lists
• Chromium (with uBlock origin) when necessary as some websites are allergic to Firefox
• Unbound (DNS Resolver) on pfSense in full recursive mode
• pfBlockerNG with regularly maintained comprehensive ad, phishing and malware block lists such as oisd.nl and hagezi
• pfSense + pfBlockerNG to block known DoH servers by domain and IP address with the understanding that 100% blocking of DoH via domain and IP is futile.
• Configure Unbound to respond with NXDOMAIN for a small popular set of DoH domains. Some devices are grumpy when the DNS response for a DoH domain is 0.0.0.0 or 10.0.0.1.
• NAT redirection in pfSense firewall rules to redirect all DNS queries over port 53 back to the pfSense box. Some devices will report "no internet connectivity" when denied DNS queries over port 53 and a hard coded IP.

[netboy]

@totowentsouth Wow!! Thanks

@totowentsouth said in Your connection is not private:

Unbound (DNS Resolver) on pfSense in full recursive mode

Can you please explain to a non-network person in "english" what does this do?

uBlock origin
I installed this in Chrome and voila the googleservices vanishes....Now I can use google chrome without the annoyance. since this solves the googleservices what is the use case to use qwant.com for searches?

[johnpoz]

@netboy said in Your connection is not private:

in "english" what does this do?

It resolves vs forwarding.

You want to look up www.domain.tld it asks the roots hey who is the name servers for .tld

Roots answer with NS for .tld

It then asks the NS for .tld hey what is the NS for domain.tld

They answer.

It go asks NS for domain.tld hey what is the A record for www.domain.tld

you get the IP address of www.domain.tld

This is how dns works..

here is a full example.. I cut down any dnssec info to keep it cleaner looking.

$ dig forum.netgate.com +trace +nodnssec

; <<>> DiG 9.16.44 <<>> forum.netgate.com +trace +nodnssec
;; global options: +cmd
.                       16609   IN      NS      h.root-servers.net.
.                       16609   IN      NS      g.root-servers.net.
.                       16609   IN      NS      f.root-servers.net.
.                       16609   IN      NS      l.root-servers.net.
.                       16609   IN      NS      b.root-servers.net.
.                       16609   IN      NS      a.root-servers.net.
.                       16609   IN      NS      d.root-servers.net.
.                       16609   IN      NS      i.root-servers.net.
.                       16609   IN      NS      e.root-servers.net.
.                       16609   IN      NS      c.root-servers.net.
.                       16609   IN      NS      m.root-servers.net.
.                       16609   IN      NS      j.root-servers.net.
.                       16609   IN      NS      k.root-servers.net.
;; Received 239 bytes from 192.168.3.10#53(192.168.3.10) in 7 ms

com.                    172800  IN      NS      c.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
com.                    172800  IN      NS      j.gtld-servers.net.
com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      e.gtld-servers.net.
com.                    172800  IN      NS      f.gtld-servers.net.
com.                    172800  IN      NS      i.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
com.                    172800  IN      NS      d.gtld-servers.net.
com.                    172800  IN      NS      g.gtld-servers.net.
com.                    172800  IN      NS      k.gtld-servers.net.
com.                    172800  IN      NS      l.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
;; Received 873 bytes from 192.5.5.241#53(f.root-servers.net) in 12 ms

netgate.com.            172800  IN      NS      ns1.netgate.com.
netgate.com.            172800  IN      NS      ns2.netgate.com.
netgate.com.            172800  IN      NS      ns3.netgate.com.
;; Received 232 bytes from 192.33.14.30#53(b.gtld-servers.net) in 27 ms

forum.netgate.com.      300     IN      A       208.123.73.83
netgate.com.            3600    IN      NS      ns3.netgate.com.
netgate.com.            3600    IN      NS      ns2.netgate.com.
netgate.com.            3600    IN      NS      ns1.netgate.com.
;; Received 276 bytes from 208.123.73.80#53(ns1.netgate.com) in 33 ms

Even when you forward to say quad9 or googledns or 1.1.1.1, there is a resolver upstream of them that they ask.. The only way to learn the IP address of some fully qualified domain name (fqdn) is to resolve..

Once a fqdn has been resolved.. Your dns server you asked will cache it for a length of time.. See the numbers there 172800, and the 3600 those are seconds.. Once something has been looked up, that is how long that lookup can be cached.

So in the above example forum.netgate.com can be cached for 300 seconds. after that have to look it up again, but since already know the ns for netgate.com and can cache them for 3600, can just go ask them directly - do not need to ask roots or gtld servers.. etc..

[netboy]

@johnpoz said in Your connection is not private:

It resolves vs forwarding.

Thank you for the detail explanation.

What is the advantage of "Resolving" vs "Forwarding" to the end user?

[johnpoz]

@netboy control.. You are talking to the horses mouth vs asking someone else..

And your not sending all your dns look ups to some company that does who knows what with them.

[netboy]

@johnpoz said in Your connection is not private:

You are talking to the horses mouth vs asking someone else..

Got it!!

[netboy]

@netboy Now how do I make sure I configure pfsense to "resolve" than "forward"? Will this change affect anything else?

[johnpoz]

@netboy it resolves out of the box, that is the default setting.. If you didn't actually enable forwarding mode its already resolving.

[netboy]

@johnpoz Wonderfull thanks

[Gertjan]

@netboy said in Your connection is not private:

What is the advantage of "Resolving" vs "Forwarding" to the end user?

See, for example, this video.
Many other video's about the same subject exist.