Netgate SG-1000 microFirewall

Author Topic: DNSBL Certificate errors  (Read 5811 times)

0 Members and 1 Guest are viewing this topic.

Offline gp-se

  • Newbie
  • *
  • Posts: 2
  • Karma: +0/-0
    • View Profile
Re: DNSBL Certificate errors
« Reply #30 on: October 31, 2017, 08:02:30 pm »
Hi folks - I was wondering if others that have upgraded to pfsense 2.4.1 are having the certificate errors again?  Previously in 2.3.4 the solution described above was working fine with the lan rule blocking any traffic to the dnsbl vip.   Post upgrade to 2.4.1 I'm getting certificate errors again from my AV solution.  This began happening immediately after upgrade of pfsense to 2.4.1.

Anyone else having this trouble?



I'm on 2.4.1 with the latest PFBlocker installed, I haven't gotten the certificate errors at all. When I was on 2.3.4 I had to edit the file or I would get certificate errors.

Offline repomanz

  • Jr. Member
  • **
  • Posts: 38
  • Karma: +0/-0
    • View Profile
Re: DNSBL Certificate errors
« Reply #31 on: October 31, 2017, 08:36:49 pm »
Can you share your dnsbl configuration and any lan / float rules you may have on this?  I'm hoping it's some minor configuration change i need to make instead of a full re-install.

Offline Sekrit

  • Jr. Member
  • **
  • Posts: 33
  • Karma: +0/-0
    • View Profile
Re: DNSBL Certificate errors
« Reply #32 on: November 10, 2017, 05:30:18 pm »
No more certificate errors on the 2.4.1 and latest version of pfblocker.  This was a fresh installation.
pfSense 2.3.3-p1 (PFblockerNG, Snort, Squid).  VMware on Supermicro X11SSH-LN4F, Xeon E3-1425 v5, 16Gb

Offline HeMaN

  • Newbie
  • *
  • Posts: 15
  • Karma: +0/-0
    • View Profile
Re: DNSBL Certificate errors
« Reply #33 on: November 12, 2017, 09:59:37 am »
anyone figured out (with pfblockerng 2.1.2-1) why blocking of 127.0.0.1 or 10.10.10.1 port 8443 is not working anymore to stop the certificate error messages with the current version of pfsesne (2.4.1)?

Is there a solution that does not include the editing of the inc-file with 0.0.0.0?

Offline repomanz

  • Jr. Member
  • **
  • Posts: 38
  • Karma: +0/-0
    • View Profile
Re: DNSBL Certificate errors
« Reply #34 on: November 12, 2017, 12:21:48 pm »
I still have the issue. Currently i have dnsbl turned off and using pihole until it get's figured out. 

Offline BBcan177

  • Moderator
  • Hero Member
  • *****
  • Posts: 2608
  • Karma: +821/-5
    • View Profile
    • Click for Support
Re: DNSBL Certificate errors
« Reply #35 on: November 12, 2017, 05:13:53 pm »
anyone figured out (with pfblockerng 2.1.2-1) why blocking of 127.0.0.1 or 10.10.10.1 port 8443 is not working anymore to stop the certificate error messages with the current version of pfsesne (2.4.1)?

Is there a solution that does not include the editing of the inc-file with 0.0.0.0?

The only thing that changed was a recent commit to add the "Filter rule association" in the NAT rules. It was not previously defined, and since was changed to "pass"...

https://github.com/pfsense/FreeBSD-ports/commit/b4afa470b6599acfd48f902322452ee426995d76#diff-2fbe23c4e674f981e4a4003fb2794b27

Next release will have functionality to force "0.0.0.0" for a DNSBL group to avoid this issue....
"Experience is something you don't get until just after you need it."

 | http://pfblockerng.com | Twitter @BBcan177  | #pfBlockerNG |

Offline HeMaN

  • Newbie
  • *
  • Posts: 15
  • Karma: +0/-0
    • View Profile
Re: DNSBL Certificate errors
« Reply #36 on: November 13, 2017, 02:51:44 pm »
thnx!!
this was the hint I was looking for ;)

I now managed to loose the error warnings by editing the line created by pfblockerNG in Firewall->Nat->Port Forward


     PFSENSE_LAN  TCP  *  *  10.10.10.1  443 (HTTPS)  127.0.0.1  8443  pfB DNSBL - DO NOT EDIT

I changed the filterrule link from "pass" to "none", since it seems to precede over the flowing rule I made to block traffic to 127.0.0.1:8443

No more certificate errors for me


PS
I think a floating rule to block 10.10.10.1:443 might work as well (now I was trying to block 10.10.10.1:8443 but that port was not being used after all)

Offline hkirschk

  • Newbie
  • *
  • Posts: 1
  • Karma: +0/-0
    • View Profile
Re: DNSBL Certificate errors
« Reply #37 on: December 12, 2017, 09:32:40 am »
Here are my observations and solution proposals regarding certificate handling, pfBlockerNG and macOS.

Configuration

I'm using macOS clients version 10.13.2, Safari version 11.0.2, pfSense version 2.4.2-RELEASE, pfBlockerNG version 2.1.2_2. I did not try those modified pfSense firewall rules as explained in the posts here, but kept the pfSense and pfBLockerNG configuration as unchanged as possible, i.e. no changes to firewall rules as set up by pfBlockerNG, and also no changes to php files directly.

What I observed:

  • When clicking on URLs in Safari whose DNS names were blacklisted by pfBlockerNG, I received an invalid certificate warning by Safari, asking me to confirm that I want to continue loading that page, which then should result in that 1x1 pixel image delivered by the pfBlockerNG lighttpd_pfb process. Technically, confirming to load such a page results in an entry into the macOS keychain marking certificate CN_DNSBL as trusted so that Safari should continue loading that page. I was asked over and over again for that load confirmation, even after having confirmed the certificate, and never ended up with that 1x1 pixel image of pfBlockerNG.
  • What also happened from time to time, the php-fpm process running on the pfsense did not answer any more. Calling the URLs https://10.10.10.1:8443 or http://10.10.10.1:8081 timed out in Safari. All I could do was a hard reboot of pfSense, even the ssh login to the pfsense machine stalled at the place where /etc/rc.initial calls /etc/rc.banner, I had to suspend the login to the pfsense by Control-Z, receiving a shell prompt then for reboot. Restarting the php-fpm process itself was not possible, it did not react to any kill request. This behaviour was quite annoying, since i had to reboot pfSense sometimes after a few hours, latest after a few days. This happened first some time after I upgraded to macOS Sierra, if I remember right.

Possible root causes:

More or less by chance I looked into the macOS keychain and found several instances of CN_DNSBL certificates, obviously with the same name and only differentiated by their finger print (and associated data, like `valid from', `valid to' date). When deleting all those certificates named CN_DNSBL from keychain, things began to work as expected: I have only been asked once by Safari for certificate & load confirmation, and the pfBlockerNG 1x1 pixel page loads as expected. No need for regular reboots of pfSense any more, and pfBlockerNG logging keeps on working.

  • So I guess the root cause for observation 1. is that Safari picks the certificate to check against from the keychain by name (CN_DNSBL), and if there is more than one instance with the same name it constantly picks the wrong certificate, the one from the keychain which does not match the certificate delivered by the 1x1 pixel server of pfBlockerNG.
  • I have no real explanation for observation 2., that stalled php-fpm process, I guess this happened because pfBlockerNG was flooded by requests coming from Safari, and at some point in time that process dived into some race condition. php-fpm stalled very often when I called pages in Safari where pretty much of its content was blacklisted by pfBlockerNG.

Solutions/workarounds:

  • Workaround 1: With each update of pfBlockerNG, a new instance of the CN_DNSBL certificate gets installed, thus use keychain utilitiy on each macOS client to remove all CN_DNSBL certificates after a pfBlockerNG update. Means touching every macOS client manually, or to have some clever shell script doing this (semi-)automatically.
  • Solution 2.a: pfBlockerNG should always use the same CN_DNSBL certificate, it should not change after an update. That way, the keychain utility will not store multiple instances of CN_DNSBL.
  • Solution 2.b: Introduce a drop down in the pfBlockerNG configuration where the user can select a certificate stored in pfSense' certificate manager.

Personally, I would prefer solution 2.b. That way I can install a self signed CA as trusted to my private machines & use a certificate for the 1x1 pixel server signed by my own CA.
« Last Edit: December 12, 2017, 10:38:08 am by hkirschk »

Online jdeloach

  • Jr. Member
  • **
  • Posts: 28
  • Karma: +1/-0
    • View Profile
Re: DNSBL Certificate errors
« Reply #38 on: February 03, 2018, 07:54:23 pm »
Has anybody come up with a way to stop the DNSBL certificate errors when going to different web sites using IE 11 in windows?  I see lots messages about this but doesn't seem to be any solution yet.  I just started using DNSBL but looks like I need to hold off till there is a solution to these annoying errors.

Offline HeMaN

  • Newbie
  • *
  • Posts: 15
  • Karma: +0/-0
    • View Profile
Re: DNSBL Certificate errors
« Reply #39 on: February 05, 2018, 03:42:25 am »
anyone figured out (with pfblockerng 2.1.2-1) why blocking of 127.0.0.1 or 10.10.10.1 port 8443 is not working anymore to stop the certificate error messages with the current version of pfsesne (2.4.1)?

Is there a solution that does not include the editing of the inc-file with 0.0.0.0?

The only thing that changed was a recent commit to add the "Filter rule association" in the NAT rules. It was not previously defined, and since was changed to "pass"...

https://github.com/pfsense/FreeBSD-ports/commit/b4afa470b6599acfd48f902322452ee426995d76#diff-2fbe23c4e674f981e4a4003fb2794b27

Next release will have functionality to force "0.0.0.0" for a DNSBL group to avoid this issue....

I manually removed the "pass" you added to the code, and now the firewall rules are working again.
I had to remove it from the code, because if I manually edited the FW rule, the next time the definitions were reloaded the rule was changed back.

Happily waiting for the new version :)