Pfsense 2.2.2 + squid3 transparent HTTP/HTTPS proxy "Facebook partially loading"
-
Hi,
I recently install pfsense 2.2.2 + squid3 transparent HTTP/HTTPs proxy.
I noticed a weird problem when www.facebook.com page is partially loaded when behind proxy.
I cannot understand the reason, why it fails to completely load while other sites are fully operational.
Can anyone assist in understanding this problem and why it happen?
Many Thanks,
Nissim.
-
Are you 100% sure your transparent proxy handles HTTPS ;)
-
100% sure.
All other sites are working with HTTPS other than facebook and CDNs …
Can anyone please assist?
How can I tell squid to bypass for these domains? it looks like bypass for destination domains is not working ...
Best Regards,
Nissim.
-
I was asking because with transparent proxy, unless you implement "man in the middle", HTTPS flow doesn't go through Squid but directly through pfSense.
Therefore depending on your configuration this might be or not Squid related issue ;) -
Hi there.
I am facing the same problem. But it happens only in Firefox. And looks like only with FB. Other sites (google, pfsense, banks) seems to be working fine.
And what is more surprising that Google Chrome displays the very same facebook page correctly.
Any ideas what is wrong?
-
guys already solved this problem?
-
Same problem here!
I use pfSense 2.2.2 + squid3 ( Transparent or marked in the browser) + SquidGuard .
No matter what browser
If I disable SSL on Squid everything returns to normal.
I do not know what to do. Just with Facebook.
Please someone help us?
-
The certificate created in pfsense not trust in akamaihd.net
See:
GET https://fbstatic-a.akamaihd.net/rsrc.php/v2/yG/r/a92XwleskLR.css HTTP/1.1 Host: fbstatic-a.akamaihd.net Connection: keep-alive Cache-Control: max-age=0 Accept: text/css,*/*;q=0.1 If-Modified-Since: Mon, 01 Jan 2001 08:00:00 GMT CSP: active User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.124 Safari/537.36 Referer: https://www.facebook.com/ Accept-Encoding: gzip, deflate, sdch Accept-Language: pt-BR,pt;q=0.8,en-US;q=0.6,en;q=0.4 HTTP/1.1 503 Service Unavailable Server: squid Mime-Version: 1.0 Date: Sun, 21 Jun 2015 00:21:31 GMT Content-Type: text/html Content-Length: 3803 X-Squid-Error: ERR_SECURE_CONNECT_FAIL 92 Vary: Accept-Language Content-Language: pt-br X-Cache: MISS from IEECD X-Cache-Lookup: NONE from IEECD:3128 Via: 1.1 IEECD (squid) Connection: close
I tried to use:
always_direct allow all ssl_bump server-first all
unsuccessfully …
I tried:
acl BrokenButTrustedServers dstdomain example.com sslproxy_cert_error allow BrokenButTrustedServers sslproxy_cert_error deny
But it has many hosts. But the page carried a lot better.
The only way that it loads perfectly and when I click: "Do not verify remote certificate"
But I do not consider this correct solution.
Can anyone help?
-
The certificate created in pfsense not trust in akamaihd.net
No shit. Browsers do not trust MITM certificates by default? Shocking news!
You might want to read this before trying to "fix" your malicious setup: https://forum.pfsense.org/index.php?topic=93188.0
-
No shit. Browsers do not trust MITM certificates by default? Shocking news!
That's not his problem. His browser trusts his "attack" cert perfectly fine. The PFSense OS doesn't trust the akamaihd.net cert.
I'm too lazy to dig into what certs PFSense trusts, but likely akamiahd is using a Certificate Authority not trusted by PFSense. I'm not sure what PFSense's policy is on keeping the root certs up to date, but changes are made to that list all the time. You should be able to obtain that root cert and add it into your trusted store yourself.
-
Good Night Guys,
I´m the same problem, but using only transparent´s squid work normally facebook according to the pictures below "see the options Remote Cert Checks are do not verify remote certificate" When allow the options in Remote Cert Checks: do not verify remote Certificate. But When to allow options in Remote Cert Checks: Accept remote server certificate Errors open only misconfigured pages and other don´t load.
When I do integrated with squid-guard , load for me this error in browser (ssl_error_rx_record_too_long) according to the last pictures below.
-
The problem with akamaidhd.net still persists as today. Has someone found a good solution? I've disabled SSL interception on my SquidProxy, but it would be good to turn it on again in near future.
-
Just a suggestion…
What if you whitelist fb in the proxy filter, and instead make blocking/ limiting rules in firewall based on fb's IPs? It will be quite long list of IPs, but you can make an alias and work with it.
-
same problem :'(
-
@JuniorAndrade:
same problem :'(
Its simple, you should selected "Do not verify remote cert" on the webgui proxy server.
-
@91X:
Its simple, you should selected "Do not verify remote cert" on the webgui proxy server.
Issue might not be with the remote certificate but the one generated at proxy level that is not signed by trusted CA. Such control, if any, depends on remote side.
Frankly I'm not using such MITM feature that I perceive as a way of twisting the HTTPS concept but if implementing such stuff is totally mandatory for you, why not using at proxy level certificate signed by well known CA? This should solve the issue, as far as I understand 8)
Not verifying remote cert in proxy server webgui means that proxy doesn't check is remote web server is using trusted certificate. I'll be surprised if either facebook or CDN do not rely on such private certs or certificates signed with CA not in pfSense "trusted CA" repository but why not… ??? To be checked.
-
Sorry to revive an old thread, but I too am having the exact same issue with pfSense 2.2.5 (Squid3 - 0.4.2 - 3.4 branch). I noticed the problem is happening to me even when I turn the transparent mode off and manually connect to the proxy as well.
Has anyone found a solution other than the "do not verify" option that has been mentioned? That doesn't seem like a safe solution given that I can't use that option only for Facebook.
-
If you're running in explicit mode then you should not have any of the SSL Interception stuff enabled. It's only for transparent mode.
-
@KOM:
If you're running in explicit mode then you should not have any of the SSL Interception stuff enabled. It's only for transparent mode.
If you don't mind, I'm not 100% in line with this statement :-\
Not discussing about the "is it acceptable to deploy MITM or not?" debate, once you decide to go for this, it may help for both explicit and transparent proxy design, as far a I understand. It will help much more with transparent proxy, I do agree but what MITM will bring is, even for explicit proxy, capability to analyse HTTP content, e.g. with anti-virus.
Without MITM, explicit proxy is only able to control CONNECT and therefore decide if access to given URL is authorized (e.g. Squidguard) but content is encrypted.
With MITM enabled, you have 2 different connections with Squid in the middle, able to look at content.Am I correct? ???
-
My understanding was that the proxies act in exactly the same way where content is concerned, regardless of mode.