Squid MITM SquidGuard Not Showing Default Error Page?

periko

Hi people.

I'm testing pfsense MITM wth squid+SG under pfsense 2.4.2, excellent job.

Now, working with the SG blocking pages, I got this doubt, if squid+SG now can read data from http or https, why went a page is been block sometimes appear the classic SQ block pages:

Request denied by pfSense proxy: 403 Forbidden
Reason:
Client address: 192.168.6.104
Client name: 192.168.6.104
Client group: BeBe
Target group: none
URL: http://www.osnews.com/

With a https, won't let u access but won't show u the same info where u know something block u, just show me a page with this info:

This site can’t be reached
openpay.mx unexpectedly closed the connection.
Try:

Checking the connection
Checking the proxy and the firewall
Running Windows Network Diagnostics
ERR_CONNECTION_CLOSED

Can some clarify this please.

Thanks.

Tecnergy

Hi,

This is a known behaviour from the browsers since a long time ago (2009), you can't redirect HTTPS connections. As I understand it, the client tries to conect to the destination via HTTPS and when it doesn't receives the expected "handshake" it drops the encrypted tunnel completely, thus, you can't send a redirection instruction. https://bugzilla.mozilla.org/show_bug.cgi?id=493699
However, after doing some research I found this statement:

"fixes this issue by first letting the CONNECT tunnel succeed and later blocking first request on this tunnel. Now users are able to see Blocked Page in HTTPS request too!" from: https://docs.diladele.com/faq/squid/cannot_connect_to_site_using_https.html

_"Please note if you first let the connect tunnel to succeed (forcing bump) and then block the next coming request through that tunnel - you will get the blocked message displayed.

We do it in ICAP (https://docs.diladele.com/faq/squid/cannot_connect_to_site_using_https.html) - other community members may know better if it is possible to do that in Squid directly.

Beware of those using your tunnels to pump non http traffic though. Blocking the connect as it is done now in Squid keeps you on safe side.
"_

https://wiki.squid-cache.org/Features/ICAP

This is all chinese to me, so I hope a more intelligent person can help us to understand if it can be done with a bit of work in squid.

periko

We have to read read and read… ;D
Let see what happen, thanks Hermosillo(Sonora?).

Tecnergy

maybe this can help

http://www.squid-cache.org/Doc/config/ssl_bump/

By using bump and then action "terminate" maybe, don't know, as I've said I don't understand much.

Tecnergy

Here is the answer I think, but I can't decipher it:

Delayed error responses
When Squid fails to negotiate a secure connection with the origin server and bump-ssl-server-first is enabled, Squid remembers the error page and serves it after establishing the secure connection with the client and receiving the first encrypted client request. The error is served securely. The same approach is used for Squid redirect messages configured via deny_info. This error delay is implemented because (a) browsers like FireFox and Chromium do not display CONNECT errors correctly and (b) intercepted SSL connections must wait for the first request to serve an error.
Furthermore, when Squid encounters an error, it uses a trusted certificate with minimal properties to encrypt the connection with the client. If we try to mimic the true broken certificate instead, the user will get a browser error dialog and then, if user allows, the Squid error page with essentially the same (and possibly more detailed/friendly) information about the problem. Using a trusted certificate avoids this "double error" effect in many cases. And, after all, the information is coming from Squid and not the origin server so it is kind of wrong to mimic broken origin server details when serving that information.
Squid closes the client connection after serving the error so that no requests are sent to the broken server.
It is important to understand that Squid can be configured to ignore or tolerate certain SSL connection establishment errors using sslproxy_cert_error. If the error is allowed, Squid forgets about the error, mimics true broken certificate properties, and continues to talk to the server. Otherwise, Squid does not mimic and terminates the server connection as discussed above. Thus, if you want users to see broken certificate properties instead of Squid error pages, you must tell Squid to ignore the error.

from https://wiki.squid-cache.org/Features/MimicSslServerCert