Certificate error with squid in manual mode

NethServer Version: 7RC3
Module: squid and squidguard (using Internet Explorer)
Hi,
I’ve a little problem with the certificate. I’ve installed squid (manual not transparent) and squidguard to block sites like facebook.
If I try to open https://www.facebook.com I get an error that the certificate is for another site. If I choose to go on loading the site I can see https://www.facebook.com in the adressbar but it opens a nethserver site. The certificate what is loaded is for nethserver.
Can somebody explain me how to get away the error message?
Thanks in advance

Can you reproduce the problem with firefox or chrome?
I tried both browsers and I can’t replicate your findings.
The description of the problem is the effective behavior of the blocking of https web sites:
we can’t “inject” a block page into an encrypted session.

I tried with firefox. There are two errors.

  • Firefox says it dosn’t trust the certificate because it’s self-signed (I’ve imported it before)
  • Firefox says the certificate dosn’t apply to www.facebook.net

This is the expected behavior.

With ns6.8 it works:

with ns7 it doesn’t work:

Both with chrome and installed certificate.

IE also says “The certificate of this website is made for another website.” with the ns7-certificate.
Chrome says: net::ERR_CERT_AUTHORITY_INVALID

The only difference I found is CN=NethServer from ns7-certicifacte, but CN=example.domain.com from ns6-certificate.

2 Likes

I’m probably not understanding the problem, sorry.
You want to block facebook.com, you don’t want to view facebook, you can’t view it.
I agree it would be nice to show a page that says “you can’t go to facebook”, but we can’t modify an encrypted connection.
We may find a trick to convince the browser to go elsewhere, but it may stop working with a different or newer version of the browser.

Can you explain me why the adressbar shows https://www.facebook.de but I see a Nethserver side

I think this is the problem.

1 Like

I don’t want a certificate error. Because users can’t differentiate if it is a site they don’t have to open or maybe an other problem with a certificate.

Agreed.
Unfortunately, the redirection of a blocked https url can’t go to a webpage, only to a FQDN.
We could build an appropriate page globally available at something like “https://blocked.nethserver.org/” and redirect all nethserver installations to the url by default, leaving the option to the admin to host a customized page where he/she prefers.

Please, try the following customizations as a proof of concept, if it’s okay I’ll update the package:

echo "redirect-https     \"blockedhttps.urlfilterdb.com:443\"" >/etc/e-smith/templates-custom/etc/ufdbguard/ufdbGuard.conf/18redirect-https
expand-template /etc/ufdbguard/ufdbGuard.conf
/usr/sbin/ufdbsignal -C "sighup ufdbguardd"

Thank you.

3 Likes

Hi,
I’ve done your steps, but I get still a certificate error but not the same as before.


IE still says that the certificate is for another site.

I quote myself:

Honestly, I’m out of ideas. Browsers are implementing stricter checks on certificates to protect the users from attackers. We may find a “fix”, but how long will it work?

I’ll make some more tests in the afternoon. I’ll keep you informed.

1 Like

Which Firefox version do you use? Can you try it with IE 11 to please.

Perhaps we can find the reason for working in 6.8 but not in 7.

Hi Michael, thank you for reply.

I found a solution this morning. I changed the issuer from NethSserver (default) to the FQDN and generatet a new certificate. Now the the certificate is shown as trusted.

Chrome
IE 11 works also.

Thanks for your answer, my issuer is my FQDN (groupware.jonas)

I think I have an other problem, the Browser wants to have a certifcate for the redirected site like https://www.facebook.com, but it gets my own certificate for groupware.jonas.

I re-read a lot of documentation and made some tests. My conclusion is that there’s no technical way to show a clear block page to the user with current browsers.
I can quote ufdbguard documentation:

5.7 Redirection of HTTPS-based URLs
Squid requires that HTTP-based URLS are redirected to other HTTP-based URLs and that HTTPS-
based URLS are redirected to other HTTPS-based URLs. This causes a problem since most web
browsers do not accept a redirection of a HTTPS-based URL. There is no solution for this issue: the
standards of HTTP, ICAP and web proxies do not have support for such feature. Basically, this means
that blocked HTTPS-based sites cause unexpected browser-generated error messages like “cannot
connect to www.example.com” or “www.example.com does not have a valid SSL certificate”.

You can read chapter 3.1 (https://www.urlfilterdb.com/files/downloads/ReferenceManual.pdf).

In 6.8 we used a different redirector (squidGuard) which is not https aware and no longer compatible with newest squid versions.

We may find a different redirector, but I think that’s a protocol and browser issue, we have no control over them.

I appreciate your opinions and experiences with different products.

3 Likes

I created a little blockpage and put it into /var/www/html and now it shows this when I try to reach a blacklisted https-page:

But this doesn’t work with facebook, I think because of HSTS.

With “normal” blacklisted http-sites it shows the block-page of ufdbguard.

This is o.k. for me.
PS: I’m using chrome.

Hi Filippo,
thanks for your work.

Before I came to Nethserver last year I setup squid 3.5.19 with squidguard manually at Ubuntu 14.04 and it works fine.
I had to add the following lines to the squid.conf

# redirect_program
url_rewrite_program /usr/bin/squidGuard -c /etc/squidguard/squidGuard.conf
url_rewrite_children 20

Hi Ralf,
thanks for your work to.
Does it work with facebook in 6.8. If it so, can somebody explain me the difference between squidguard and urlfilterdb.

Hi Micheal,

I’m using transparent with SSL in NS6 with squidguard and it works fine to block https-sites.

The difference is explained by @filippo_carletti in this thread

I’ve to say at the moment NS6 is more suitable for my personal needs than NS7, but don’t forget it’s still RC not final. So I’m faithfull that NS7 final will fit all needs perfectly!!

2 Likes

Hi Ralf,
I think with a transparent SSL proxy you don’t have any problems with version 7 too, because your squid creates a dynamic certificate for each site. So you can’t have a wrong one.
But I can’t use the transparent version, it doesn’t work with the banking stick and it’s a big security risk.