Its working now by adding:
url_rewrite_access deny CONNECT
Your "url_redirect_access deny CONNECT" gave me error
/etc/squid/squid.conf:102 unrecognized: 'url_redirect_access'
Thank you very very much. My problem solved now and everything's running fine.
05/31/17 16:14:59, Amos Jeffries <squid3@xxxxxxxxxxxxx>:
On 31/05/17 20:15, Andi wrote:
> Squid 3.5.25 + Squidclamav(c-icap) + SquidGuard
> Here are the logs with SSL_ERROR_RX_RECORD_TOO_LONG in Firefox by
> debug_options ALL,1 11,2 and 61,5
> https://mega.nz/#!dIdAkYra!aVEg07Sc9OxRwYiRAPk49dwegr2r-sdX2u73btEdDVk
> <https://mega.nz/#%21dIdAkYra%21aVEg07Sc9OxRwYiRAPk49dwegr2r-sdX2u73btEdDVk>
>
> Here the squid.conf & squidguard.conf
> https://pastebin.com/v2LA8CcR
>
I see your SG is trying to redirect HTTPS tunnels (which are essentially
collections of multiple transactions) to a single HTTP plain-text page
URL (singular). There is a bug in Squid that is dutifully (but wrongly)
sending that response back as-is to the client. But since this is just
an intercepted TCP connection at this point the browser just mistakes it
for bogus TLS handshake bytes.
I think I saw some patches from Christos fixing some of this a while
back, but do not recall if they made it into Squid-3. There is a lot of
SSL-Bump redesign that only exists in Squid-4 these days.
SG should never be sent CONNECT messages anyway - it does not understand
them, never has AFAIK. So the workaround is simply to enforce that like so:
url_redirect_access deny CONNECT
Squid will then do any relevant bumping and pass SG the decrypted
messages you actually want it to manage.
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
