pfBlockerNG v3.2.0.8 giving This Connection Is Not Private on all apple devices, but not PC's
-
I just updated my pfSense firewal to 2.7.2 and installed a fresh copy of pfBlockerNG 3.2.0.8.
on PC computers everything works just fine. on my apple products ipad & iphone if I google something it displays just fine. if I try to select a google search result (any result) I get the "This Connection is not private" screen using show details it tells me the website may be impersonating ad.doubleclick.net it started with googleadservices but I whitelisted it.
I really don't want to whitelist all these things. Is there a solution to this? It's happening on safari and chrome on apple. I never had this problem on pervious versions of pfBlockerNG.
----update----
I whitelisted ads.doubleclick.net (so 2 items whitelisted), and the problem seems to have gone away. Is that my ultimate resolution or is there something else I should be doing?
Thanks,Roveer
-
You can change the DNSBL “Logging/Blocking” mode for your DNSBL Group from “DNSBL Webserver/VIP” to “Null Block (no logging)”.
-
@roveer said in pfBlockerNG v3.2.0.8 giving This Connection Is Not Private on all apple devices, but not PC's:
Is there a solution to this?
There never will be, as its not a problem.
For example : your browser found a host called "ad.doubleclick.net" on a web page and this host name was 'blocked' by pfBlockerng.
What happened is : your browser asks the local DNS (pfSense) : what is the IP address of ad.doubleclick.net ? And your local DNS, the resolver will use pfBlockerng to test every DNS request. pfBlockerng will compare the requested host name "ad.doubleclick.net" with a list of 'forbidden' host names, the DNSBL feeds you've installed into pfBlockerng.
And guess what : there was a match ! 'ad.doubleclick.net' was present on some DNSBL list, so the resolver stops doing it work (resolving 'ad.doubleclick.net') and it will return to the browser the IP : (pfBlockerng default) "10.10.10.1".
Ok, the browser is happy, now it will connect to that IP, and show the user what it has to 'say'.Meanwhile, the way how browsers connect to web servers has changed since the last century.
Entering TLS, or what is "https" ?
https is http, with and s added to it. It's the http protocol, encrypted (secured) with TLS.Before : the browser would connection to the server IP, and ask on port '80' : "gime the page" - and done.
These days : the same thing but over a secured communication link. This means that the browser gets a certificate from the web server first.Lets take the example of the certificate of this web site 'forum.netgate.com' : embedded in the certificate (check for yourself) you can find :
Your browser, before accepting the connection with 'forum.netgate.com', will compare what it found in the certificate from the forum.netgate.com web server, with what it tries to contact : does 'forum.netgate.com' match '*.netgate.com' ? And it does !! so the connection has a pad lock, and the browser is happy. All is well. Many children, Bright future. etc.
Now, wind back to our our 'ad.doubleclick.net ' and 10.10.10.1 answering. Will '10.10.10.1' be able to produce a certificat to the browser that says "'I am 'ad.doubleclick.net' " ? Of course not.
Now your browser will yell at you .... as it want to connect to a server called 'ad.doubleclick.net' and it got an answer back from an other server called (I don't know, but not 'ad.doubleclick.net') ... that is bad ! Massive errors will show up. Users are panicking. "Internet is broken again"To make the long story short : and @dave14305 is right, forget about the pfBlockerng build in web server that will show the user a pfBlockerng web page if he's trying to visit a web site that is blocked.
It is impossible to redirect https traffic - period. The pfBlockerng web server was nice to have when web sites were 'http' only (last century). And that doesn't exist anymore.Set up the “Null Block (no logging)” option, and be done with it. Some day, our browser will make the 'error' shown more 'clear' to the end user. Maybe ....
Btw : I've a load of "apple products ipad & iphone" in use here, I'm even using one right now to write this post.
I didn't saw any "This Connection is not private" issues.
That is, it is still complaining that my Wifi isn't encrypted but I don't care ???!! Everything (mostly) is already flowing over the Wifi (radio waves) using TLS so what is the risk ?
I could of course activate WPA2 for my wifi (and now I have to deal with the passwords).
I could, as soon as the wifi is activated, fire up a VPN.
And now I have a secured connection in a secured connection in a secured connection.
Now I buy safely my new thin foiled hat.
