[squid-users] Unable to open youtube.com

Thu Oct 18 13:03:04 UTC 2018

Dear friends,

I have good news!
i upgraded my openssl package from openssl-1.0.2 up to openssl111 (FreeBSD
11.2)
this action has resolved the issues with youtube.com and some other sites.
now everything works perfect.

thank you very much for your attention!
best regards!

ср, 17 окт. 2018 г. в 10:37, Timur Lagutenko <timur.lagutenko at gmail.com>:

> I will try fresh installation of FreeBSD 11.2-RELEASE
> And see how it works.
> Maybe something was corrupted during upgrade.
>
> Just FYI please look on my pf.conf and squid.conf:
>
>
> *# cat /etc/pf.conf*
> outif=re0                       #outer interface
> inif=re1                        #iner interface
> outip="(" $outif ")"            #outer ip
> inip="(" $inif ")"              #iner ip
> innw=$inif:network              #iner network
> inbc=$inif:broadcast            #iner broadcast
> bc="255.255.255.255"            #anycast
>
> set skip on lo0
> set block-policy drop
> scrub in all
>
> nat on $outif from $innw to any -> $outip
> rdr on $inif proto {tcp,udp} from $innw to any port 123 -> $inip port 123
>
> block log all
>
> pass from $innw to $innw
>
> # this is my machine client ip
> # i have allowed full access form my PC
> pass from 192.168.0.104 to any
>
> # this 2 lines passes any traffic from gateway itself
> pass from $outip to any
> pass from $inip to any
>
> # i don't know why but option "set skip on lo0" doesn't work
> # so i additionally pass the whole traffic thru loopback interface
> pass on lo0 from any to any
>
>
> ###########################################################################
>
>
> *# cat /usr/local/etc/squid/squid.conf*
> visible_hostname "Squid on freebsd"
> acl localnet src 192.168.0.0/20 # RFC1918 possible internal network
> shutdown_lifetime 5 seconds
> access_log daemon:/var/log/squid/access.log squid
>
> acl SSL_ports port 1-65535
> acl Safe_ports port 1-65535
> acl CONNECT method CONNECT
>
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
>
> http_access allow localnet manager
> http_access deny manager
>
> http_access deny to_localhost
>
> #
> # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
> #
>
>
> acl baddom dstdomain ardownload.adobe.com agsupdate.adobe.com \
> .microsoft.com .windowsupdates.com .oneclient.sfx.ms \
> .windows.com .windowsupdate.com
>
> acl bdx dstdom_regex -n -i porn
>
> http_access deny bdx
> http_access deny baddom
>
> http_access allow localnet
> http_access allow localhost
>
> http_access deny all
>
> http_port 192.168.0.254:3128
> # in future i have plans for 3129 port
> # for now it simple listening additional port
> http_port 192.168.0.254:3129
>
> cache_dir ufs /var/squid/cache 10240 8 16
> maximum_object_size 4096 MB
> coredump_dir /var/squid/cache
>
> quick_abort_min -1 KB
>
> refresh_pattern ^ftp:           1440    20%     10080
> refresh_pattern ^gopher:        1440    0%      1440
> refresh_pattern -i (/cgi-bin/) 0        0%      0
> refresh_pattern .               0       20%     4320
>
>
>
>
>
>
> ср, 17 окт. 2018 г. в 10:06, Amos Jeffries <squid3 at treenet.co.nz>:
>
>> On 17/10/18 5:17 PM, Timur Lagutenko wrote:
>> > i'm sure that the issue is not related to firewall rules.
>> > because if I pass traffic from client IP (using NAT, browser is not
>> > configured to use proxy) it works.
>>
>> Ah, you said earlier that you did not have SSL-Bump features enabled.
>>
>> How are you intercepting the port 443 HTTPS traffic with NAT and
>> converting it to port 80 or 3128 syntax HTTP for Squid to handle?
>>
>> Squid cannot MITM the "raw" port 443 TLS without SSL-Bump being
>> configured.
>>
>>
>> Also since it is a Google service it may not be using TCP port 443 at
>> all. It may actually be performing their QUIC protocol instead of HTTPS.
>> That has to be blocked entirely to be sure the proxy is actually
>> receiving all the relevant traffic.
>>
>>
>>
>> > I think it is related to some SSL/TLS lib in the system.
>> > Because today i've tried CLI browser - links.
>> > Launching it directly from gateway (which has direct access to web), i
>> > was able to browse any site in text mode.
>> > Except youtube.
>> > So i guess it is related to some missing ssl lib.
>> > Could you please suggest how can i find all required libs for my squid?
>> >
>>
>> If Squid starts without crashing the libs it has been compiled to use
>> are present on your machine.
>>
>> If you built it yourself on the same machine, it only uses library
>> features that machine had at time of the build - so maybe a rebuild is
>> needed to get access to newer library features.
>>
>> When it comes to TLS though the library itself is doing the config parse
>> and setup for crypto things. So Squid does not particularly need to even
>> be configured to use features the library enables by default. Which
>> usually includes the current industry-standard ciphers etc.
>>
>>
>> If Squid accepts your config file and does not produce an ERROR or FATAL
>> message when you run "squid -k parse" all the libs required to run your
>> config have been compiled in and loaded.
>>
>>
>> > # squid -v
>> > Squid Cache: Version 3.5.28
>> > Service Name: squid
>> >
>> > This binary uses OpenSSL 1.0.2p  14 Aug 2018. For legal restrictions on
>> > distribution see https://www.openssl.org/source/license.html
>>
>>
>> Your problem may be TLS/1.3 related. OpenSSL 1.0.* only supports a max
>> of TLS/1.2. Squid-3.5 also only supports OpenSSL 1.0.* library.
>>
>> AFAIK, Google are one of the organizations heavily pushing TLS changes
>> and bias their services towards forcing the latest crypto whenever they
>> can. It is strange that others have not reported issues en-mass, so this
>> is somewhat unlikely.
>>
>>
>> Other admin mentioning similar behaviour with YouTube have turned out to
>> be TLS restrictions that pretty much prohibit the weaker crypto Google
>> services still allow and only let the very advanced ones (not supported
>> by their Squid) work.
>>
>> But also those restrictions were done via SSL-Bump configs. Since you
>> don't use SSL-Bump it is unlikely to be the same - which leaves us only
>> with the network/firewall level issues as known things to look at.
>>
>> Amos
>> _______________________________________________
>> squid-users mailing list
>> squid-users at lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-users
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20181018/6620f512/attachment.html>