3.4.0 secure site issue

[Mike K]

We are needing to get the secure site filtering working properly, so I found you had the 3.4.0 released (we already use 3.1.2 and 3.2.0 on other production servers). Today on a testing server, I upgraded and it works normally as before, EXCEPT many secure sites refuse to load due to invalid certificate. It is reading my server certificate instead of the originating site certificate. Even when the certificate exception is allowed by Firefox, it still ends up blocked (second error mentioned below). I have tried it with "sslcertcheck = off", "mitmcheckcert = off", sites in nocheckcertsitelist, and no matter what, either it refuses to load, displays the block page due to invalid certificate, or fails with the certificate error. So far I have not found a single secure site that actually works. Something else worth mentioning is /var/log/messages does show "Feb 17 14:23:50 GTWE1 e2guardian[1140]: error creating certificate sub-directory", even though the directory is /etc/e2guardian/certs/.



Example, Facebook gives this error in Firefox:

***

This Connection is Untrusted

You have asked Firefox to connect securely to www.facebook.com, but we can't confirm that your connection is secure.

Normally, when you try to connect securely, sites will present trusted identification to prove that you are going to the right place. However, this site's identity can't be verified.

What Should I Do?

If you usually connect to this site without problems, this error could mean that someone is trying to impersonate the site, and you shouldn't continue.

This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox only connect to it securely. As a result, it is not possible to add an exception for this certificate.

www.facebook.com uses an invalid security certificate.

The certificate is not trusted because the issuer certificate is unknown.

The server might not be sending the appropriate intermediate certificates.

An additional root certificate may need to be imported.

(Error code: sec_error_unknown_issuer)

***

Others like https://local.nixle.com/okaloosa-county-sheriffs-office/ starts with the option to add a certificate exemption, then displays the blocked page:

***
Access to the page:

https://local.nixle.com

... has been denied for the following reason:

Certificate supplied by server was not valid

Categories:

SSL SITE
***

So any ideas or suggestion on how to get e2guardian to retrieve the originating servers certificate before it cracks it open to do the filtering?
I have the latest stable squid 3.5.14 working, and I can use that directly as the proxy (for both HTTP and Secure) and all sites work fine, so it is something in E2G that is causing it. The code in E2G would still point to our server instead of originating server (facebook, nixle, startpage, etc).

[Mike K]

And the entry/errors in the /var/log/e2g.log is this:

2016.2.17 14:56:55 - 192.168.2.113 https://authserver.cordys.com:443 *DENIED* Certificate supplied by server was not valid: self signed certificate in certificate chain CONNECT 0 0 SSL SITE 1 200 -     - -
2016.2.17 14:55:54 - 192.168.2.113 https://urs.microsoft.com:443 *DENIED* Certificate supplied by server was not valid: unable to get local issuer certificate CONNECT 0 0 SSL SITE 1 200 -     - -
2016.2.17 14:41:30 - 192.168.2.113 https://safesearch.avira.com:443 *DENIED* Certificate supplied by server was not valid: unable to get local issuer certificate CONNECT 0 0 SSL SITE 1 200 -     - -
2016.2.17 14:38:52 - 192.168.2.113 https://gmail.com:443 *DENIED* Certificate supplied by server was not valid: unable to get local issuer certificate CONNECT 0 0 SSL SITE 1 200 -     - -

Yet the squid logs show
1455742554.243    363 127.0.0.1 TCP_TUNNEL/200 3356 CONNECT urs.microsoft.com:443 - HIER_DIRECT/157.56.64.121 -
1455742554.329    458 127.0.0.1 TCP_TUNNEL/200 5370 CONNECT authserver.cordys.com:443 - HIER_DIRECT/82.199.75.253 -
1455742699.106    219 127.0.0.1 TCP_TUNNEL/200 2526 CONNECT local.nixle.com:443 - HIER_DIRECT/208.75.2.182 -
1455742871.402    252 127.0.0.1 TCP_TUNNEL/200 4703 CONNECT safesearch.avira.com:443 - HIER_DIRECT/52.6.96.60 -


So squid is allowing it but E2G is not grabbing the remote server certificate for some reason. Tested in Firefox 44 and IE 11, acts the same in both.

[Mike K]

Someone mentioned folder permissions, that is not a problem, the certs folder is 771.

[FredB]

Please use the 3.4.0.2 (master's branch)
Who is the owner of this directory ?
You can also try to remove the temporary files (I mean SSLMITM files) from previous version

[Marcus Kong]

How to download 3.4.0.2?

--
You received this message because you are subscribed to the Google Groups "e2guardian" group.
To unsubscribe from this group and stop receiving emails from it, send an email to e2guardian+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[FredB]

Zip file on front page

[Mike K]

Fresh new clean 3.4.0.2 installation, having the same problem: many secure sites refuse to load due to "invalid certificate". It is reading my server "self signed" certificate instead of the originating site certificate.

[Philip Pearce]

Mike K,

1. Have you loaded the your root CA xx.crt file on the client browsers?

2. HSTS protection - this will detects MITM - so ether disable HSTS in the browser or put these sites
    into the exceptionsitelist.

3. Where you get 'self-signed cert' in e2gauardian logs, you have to decide if want to risk allowing the site, if you do, then add site to nocheckcertsitelist.

4. 'local issuer cert' errors are from openssl - search for openssl documentation on how to check these sites with openssl - check you have an up-to-date cert bundle installed in openssl library also make sure you have complied e2g with latest openssl library (at least 1.0.2) and that this library is installed on the production server.

Regards

Philip

---

--

[Mike K]

My apologies for lack of response, had other server projects come up, I have a little more time to deal with this now.
Most recently I downloaded and compiled squid 3.5.15 with ssl-bump, which by itself using the default proxy port 3128 in the browsers, everything (including HTTPS sites) work normally.
Related squid.conf entry:
http_port 3128 ssl-bump connection-auth=off generate-host-certificates=on dynamic_cert_mem_cache_size=16MB cert=/etc/squid/ssl/squid.pem key=/etc/squid/ssl/squid.key cipher=ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:AES128-SHA:RC4-SHA:HIGH:!aNULL:!MD5:!ADH


Then I downloaded and compiled e2guardian 3.4.0.4. Normal insecure HTTP sites are working normally and filtered properly but the same above mentioned issue persists with e2guardian 3.4.0.4: no secure sites work at all and when I am able to "create an exception" in Firefox or "continue to the site anyways" in IE, I am greeted with the block page stating:

Access to the page: https://www.google.com (or facebook, nixle.com, bing.com, literally ANY secure site)

... has been denied for the following reason: Certificate supplied by server was not valid

Categories: SSL SITE

In the log it shows:
2016.4.4 11:41:51 - 192.168.2.108 https://www.google.com:443 *DENIED* Certificate supplied by server was not valid: self signed certificate in certificate chain CONNECT 0 0 SSL SITE 1 200 -     - -

Based on your previous mentions:
1. der certificate has been loaded to Firefox and IE11, no change, all secure sites still do not work.
2. Disabling HSTS is not an option since this will be rolled out to customers, and we do not want to inhibit their security at the expense of filtering. Putting the site into exceptionsitelist does nothing to help, still get the same certificate error.
3. "Where you get 'self-signed cert' in e2gauardian logs, you have to decide if want to risk allowing the site, if you do, then add site to nocheckcertsitelist." - Considering I get it ALL secure sites, I would literally have to record and enter every single secure site used by thousands of people into a list, which is not an option.
4. Certs were created with the latest available openssl for my distro "OpenSSL 1.0.1e-fips" which according to the openssl website is still covered under long term support until the end of 2016. I can try 1.0.2g (latest on openssl site) but I suspect it will not make any difference.

So any further ideas?

[Philip Pearce]

The reason you are getting these messages on all https sites is because you have ssl-bump enabled in squid.  E2g is rejecting the self-signed cert generated by squid.    Not generally a good idea to bump twice, once in squid and then again in e2g!

Two suggestions:-

1.  (much preferred)  - Disable ssl-bump in squid.   Then e2g will see the real server certs!

2.  Why are you using ssl-bump?  
I can not see why it is needed and it is wasting a lot of cpu decrypting/encrypting twice. 
But, if you really must use it, then make sure squid is checking the real server certs and then there is no point in checking your squid generated cert in e2g, so set mitmcheckcert = off.    -  In theory this will work, but I have not tested it.  

Or if you really want to check your squid generated certs in e2g then you could try loading your root CA used for squid into your openssl cert bundle, although I would not recommend this as I think this may give your system a security vulnerability if the squid is running on the same host as e2g.

Note:  The setting of sslcertcheck only applies to non-mitm https sites (and also when mitm is off).  It is ignored when mitm is active on a site. So best to leave it 'off' and only enable it if needed once you have mitm working OK.

Regards
Philip

---

From: "Mike K" <screwba...@gmail.com>
To: "e2guardian" <e2gua...@googlegroups.com>
Cc: screwba...@gmail.com, "philip pearce" <philip...@e2bn.org>
Sent: Monday, 4 April, 2016 6:12:14 PM
Subject: Re: 3.4.0 secure site issue

[Mike K]

I wish that helps, but it doesn't. For a test, in squid I disabled ssl-bump, so it only uses "http_port 3128". E2guardian still uses 8080, and connects to squid via 3128. No change, same problem.
Going directly through squid itself using browser proxy port 3128 everything including secure sites work properly, versus going through browser port 8080 via e2guardian is when the same sites do not work. So this points to something in e2g not knowing how to properly handle secure sites or not executing the proper MITM.
I ran a test using mitmcheckcert = off or on
Via Firefox: on = Certificate invalid block page, off = "The connection to the server was reset while the page was loading."
Via IE 11: on = This website did not load properly, off = "This page can’t be displayed"

I even tried it with "sslcertcheck" on and off and have the same issues, so the outcome changes depending on "mitmcheckcert", does not change at all with either option under "sslcertcheck".

2. We always understood that ssl-bump is needed in order for e2g (and squid) to properly handle secure sites. Otherwise neither handles secure sites and they continue on unfiltered, or at minimum we run into the same issue we have now where most secure sites have to be passed along to squid (with ssl-bump) in order to work properly. As is, we have several production servers in use with Squid 3.5.15 (with ssl-bump enabled as previously mentioned) and e2guardian 3.0.1, 3.0.3 and one with 3.0.4 (with MITM and secure site related aspects disabled and passed to squid since they do not work in e2guardian). This is why I am using my test server trying to get this resolved before rolling it out to the production server, but keep running into the same road block.

The certs were created specifically for e2guardian with:
# openssl version
OpenSSL 1.0.2g  1 Mar 2016

are located at:

sslcertificatepath = '/etc/e2guardian/certs/'
generatedcertpath = '/etc/e2guardian/generatedcerts/'
generatedlinkpath = '/etc/e2guardian/generatedlinks/'
cacertificatepath = '/etc/e2guardian/certs/e2guardian.pem'
caprivatekeypath = '/etc/e2guardian/certs/e2guardian.key'
certprivatekeypath = '/etc/e2guardian/certs/e2guardian.key'

The certificate was also created from the above certificates and imported into Firefox, again there are no secure sites that work, they all come back with the same
Certificate supplied by server was not valid.

With the error in the log:
2016.4.4 15:50:39 - 192.168.2.108 https://www.google.com:443 *DENIED* Certificate supplied by server was not valid:  unable to get local issuer certificate CONNECT 0 0 SSL SITE 1 200 -     - -

Mike

[FredB]

Maybe it's a stupid question but are you using transparent mode or implicit with a specific browsers configuration ?

[Philip Pearce]

Mike,

See below.

---

I wish that helps, but it doesn't. For a test, in squid I disabled ssl-bump, so it only uses "http_port 3128". E2guardian still uses 8080, and connects to squid via 3128. No change, same problem.
Going directly through squid itself using browser proxy port 3128 everything including secure sites work properly, versus going through browser port 8080 via e2guardian is when the same sites do not work. So this points to something in e2g not knowing how to properly handle secure sites or not executing the proper MITM.
I ran a test using mitmcheckcert = off or on
Via Firefox: on = Certificate invalid block page, off = "The connection to the server was reset while the page was loading."
Via IE 11: on = This website did not load properly, off = "This page can’t be displayed"

With mitmcheckcert = off you are getting 'The connection....' on all secure sites?

Do you get this error if you turn ssl_mitm = off or only when it is on?

The fact that you are getting 'Certicate invalid block page' (over https) when mitmcheckcert = on means that the client to e2g encryption/decryption is working ok.  You should see your e2g self-signed CA root in the cert sent to the browser.

So the problem lies in the e2g to target host conversation - squid does not get involved here as it just supplies a connection to the target host.

2. We always understood that ssl-bump is needed in order for e2g (and squid) to properly handle secure sites. Otherwise neither handles secure sites and they continue on unfiltered,

Squid Ssl-bump has never been needed in order for e2g to properly handle secure sites - If you have ssl_mitm disabled or are using a pre-mitm e2g version then with or without ssl-bump e2g can only filter https by sitename.  I.e. Squid ssl-bump adds no functionality to e2g itself.   Although possibly you might be doing some url filtering or virus checking within squid itself?

We have hundreds of sites in production (currently with ssl_mitm on) and have never used or seen any requirement to use squid ssl-bump.

Certificate supplied by server was not valid.

With the error in the log:
2016.4.4 15:50:39 - 192.168.2.108 https://www.google.com:443 *DENIED* Certificate supplied by server was not valid:  unable to get local issuer certificate CONNECT 0 0 SSL SITE 1 200 -     - -

This error is just passed on from the openssl library so indicates an issue with openssl configuration, possibly with the sslcertificatepath settings.

You have:-

sslcertificatepath = '/etc/e2guardian/certs/'
generatedcertpath = '/etc/e2guardian/generatedcerts/'
generatedlinkpath = '/etc/e2guardian/generatedlinks/'
cacertificatepath = '/etc/e2guardian/certs/e2guardian.pem'
caprivatekeypath = '/etc/e2guardian/certs/e2guardian.key'
certprivatekeypath = '/etc/e2guardian/certs/e2guardian.key'

If used, sslcertificatepath must point to a directory containing properly formatted and indexed bundle of CA certificates which will
be used by the openssl library (not e2g itself) as the cert bundle to check target hosts certs.   I guess that you do not have such a bundle in the /etc/e2guardian/certs/ directory as this is the same directory you have your generated e2g certs/keys.  This may be resulting in the client-side openssl (the one that talks to the target host) connection not being fully set-up correctly and so always failing.
 
I would always recommend that sslcertificatepath is commented out so that the openssl libraries use the default openssl cert bundle.  This makes fixing any cert issues much easier as you can then use openssl utilities  to trace the problem  - See comments on this in e2guardian.conf and notes/certificate_errors.

Regards
Philip