On 17/04/2016 1:53 p.m., Jok Thuau wrote: > Blocking YouTube (appear to be on your list) is tricky, if the browser is chrome: > > https://en.m.wikipedia.org/wiki/QUIC > > If you click on the 'green lock' and look at the connection you will see it's not using https (funnily enough, the ads there do!). > > Look at the wiki for more info on how to block QUIC. > >> On Apr 16, 2016, at 4:10 PM, Sergio Belkin wrote: >> >> Hi, >> >> I cannot block some sites using squid 3.4.8, Please upgrade to at least the latest Squid version for SSL-Bump functionality. SSL-Bump is part of an "arms race" going on in TLS and things are still quite volatile. It is a lot of work just to keep up so we are not fixing TLS/SSL bugs unless they are still present in the latest 3.5 or 4.x releases, and debugging needs to be done using those releases. > this the configuration. On Firefox, blocking works, browser says: >> >> `Error code: SSL_ERROR_RX_RECORD_TOO_LONG` >> What you are doing there is not so much "blocking" as completely screwing up the TLS protocol traffic by injecting garbage into the binary data stream. The browser is complaining about that. It is possibly also accepting some of the garbage as TLS features being negotiated - which is highly dangerous. >> But on Chromium Versión 49.0.2623.108, browser is not affected by the blocking acl's, despite access_logs says: >> >> ```` >> 192.168.80.250 - - [16/Apr/2016:19:53:17 -0300] "CONNECT 172.217.29.14:443 HTTP/1.1" 403 3443 "-" "-" TCP_DENIED:HIER_NONE >> 192.168.80.250 - - [16/Apr/2016:19:53:17 -0300] "NONE error:invalid-request HTTP/0.0" 400 4042 "-" "-" TAG_NONE:HIER_NONE >> 192.168.80.250 - - [16/Apr/2016:19:53:17 -0300] "CONNECT 172.217.29.14:443 HTTP/1.1" 403 3443 "-" "-" TCP_DENIED:HIER_NONE >> 192.168.80.250 - - [16/Apr/2016:19:53:17 -0300] "CONNECT 172.217.29.14:443 HTTP/1.1" 403 3443 "-" "-" TCP_DENIED:HIER_NONE >> 192.168.80.250 - - [16/Apr/2016:19:53:17 -0300] "CONNECT 172.217.29.14:443 HTTP/1.1" 403 3443 "-" "-" TCP_DENIED:HIER_NONE >> 192.168.80.250 - - [16/Apr/2016:19:53:17 -0300] "NONE error:invalid-request HTTP/0.0" 400 4042 "-" "-" TAG_NONE:HIER_NONE >> 192.168.80.250 - - [16/Apr/2016:19:53:17 -0300] "CONNECT 172.217.29.14:443 HTTP/1.1" 403 3443 "-" "-" TCP_DENIED:HIER_NONE >> 192.168.80.250 - - [16/Apr/2016:19:53:17 -0300] " %BA%5D%B71A%E2%90C%BD0:Ep%82%99%FE%88 HTTP/0.0" 400 3638 "-" "-" TAG_NONE:HIER_NONE >> 192.168.80.250 - - [16/Apr/2016:19:53:17 -0300] "CONNECT 172.217.29.14:443 HTTP/1.1" 403 3443 "-" "-" TCP_DENIED:HIER_NONE >> 192.168.80.250 - - [16/Apr/2016:19:53:17 -0300] "NONE error:invalid-request HTTP/0.0" 400 4042 "-" "-" TAG_NONE:HIER_NONE >> 192.168.80.250 - - [16/Apr/2016:19:53:17 -0300] "CONNECT 172.217.29.14:443 HTTP/1.1" 403 3443 "-" "-" TCP_DENIED:HIER_NONE >> 192.168.80.250 - - [16/Apr/2016:19:53:17 -0300] "NONE error:invalid-request HTTP/0.0" 400 4042 "-" "-" TAG_NONE:HIER_NONE >> 192.168.80.250 - - [16/Apr/2016:19:53:17 -0300] " %11Tf%03%A4%83%F3%8C%EE HTTP/0.0" 400 3614 "-" "-" TAG_NONE:HIER_NONE >> 192.168.80.250 - - [16/Apr/2016:19:53:17 -0300] "NONE error:invalid-request HTTP/0.0" 400 4042 "-" "-" TAG_NONE:HIER_NONE >> 192.168.80.250 - - [16/Apr/2016:19:53:23 -0300] "CONNECT 172.217.29.14:443 HTTP/1.1" 403 3443 "-" "-" TCP_DENIED:HIER_NONE >> 192.168.80.250 - - [16/Apr/2016:19:53:23 -0300] "NONE error:invalid-request HTTP/0.0" 400 4042 "-" "-" TAG_NONE:HIER_NONE >> ```` >> >> Debugging I've found this in cache.log: >> >> ```` >> 2016/04/16 20:00:21.924 kid1| client_side.cc(864) swanSong: local=172.217.28.225:443 remote=192.168.80.250:55068 flags=33 >> 2016/04/16 20:00:21.925 kid1| Checklist.cc(62) preCheck: 0x7eff3754 checking fast ACLs >> 2016/04/16 20:00:21.925 kid1| Acl.cc(157) matches: checking access_log daemon:/var/log/squid3/access.log >> 2016/04/16 20:00:21.925 kid1| Acl.cc(157) matches: checking (access_log daemon:/var/log/squid3/access.log line) >> 2016/04/16 20:00:21.925 kid1| Acl.cc(177) matches: checked: (access_log daemon:/var/log/squid3/access.log line) = 1 >> 2016/04/16 20:00:21.926 kid1| Acl.cc(177) matches: checked: access_log daemon:/var/log/squid3/access.log = 1 >> 2016/04/16 20:00:21.926 kid1| Checklist.cc(55) markFinished: 0x7eff3754 answer ALLOWED for match >> ```` This only says that Squid is allowed to record the log messages to access.log. Dont worry about that. >> >> Please could you help? Am I missing something? Below, my configuration: >> >> ```` >> acl localnet src 192.168.0.0/16 # RFC1918 possible internal network >> acl SSL_ports port 443 >> acl Safe_ports port 80 # http >> acl Safe_ports port 21 # ftp >> acl Safe_ports port 443 # https >> acl Safe_ports port 70 # gopher >> acl Safe_ports port 210 # wais >> acl Safe_ports port 1025-65535 # unregistered ports >> acl Safe_ports port 280 # http-mgmt >> acl Safe_ports port 488 # gss-http >> acl Safe_ports port 591 # filemaker >> acl Safe_ports port 777 # multiling http >> acl CONNECT method CONNECT >> acl tvsamsung src 192.168.80.160 >> acl sarmiento src 192.168.80.248 >> acl netbook src 192.168.80.245 >> acl dompermitidos dstdomain "/etc/squid3/rules/whitelistdom" >> acl streaming dstdomain "/etc/squid3/rules/streaming" >> acl test dstdomain .debian.org >> acl streamingips dst "/etc/squid3/rules/streamingips" >> acl sergiocel src 192.168.80.249 >> acl tiempojuanse time SMTWHFA 10:00-13:00 >> acl tiempojuanse time SMTWHFA 16:00-22:00 >> acl yt dstdomain .youtube.com >> acl facebook dstdomain .facebook.com >> http_access deny !Safe_ports >> http_access deny CONNECT !SSL_ports >> http_access allow localhost manager >> http_access deny manager >> always_direct allow all always_direct is irrelevant. You are not using cache_peer. >> ssl_bump none all >> sslproxy_cert_error allow all >> sslproxy_flags DONT_VERIFY_PEER These disable all security TLS might have offered to outbound secure https:// requests made by the proxy to upstream servers. It has no relevance or effect on the traffic relayed by "ssl_bump none all". >> http_access allow tvsamsung >> http_access deny yt >> http_access allow facebook >> http_access deny streaming >> http_access deny streamingips >> http_access allow dompermitidos >> http_access allow sarmiento >> http_access allow localnet >> http_access allow localhost >> http_access deny all >> http_port 3128 >> http_port 3127 intercept >> https_port 8080 intercept ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/home/proxy/ssl_cert/example.com.cert key=/home/proxy/ssl_cert/example.com.private >> sslcrtd_program /usr/lib/squid3/ssl_crtd -s /var/spool/squid3_ssldb -M 4MB Since you have configured "ssl_bump none all" Squid does not participate in any of the HTTPS traffic it intercepts. Just blindly relays it to upstream whenever your https_access permit the CONNECT message with raw-IP to happen. That means none of these cert generation details are relevant. Only the cert= and key= parameters are used when Squid needs to send an error to the client. Your version does not appear to be doing that correctly anyway. Like Jok mentioned Chrome is probably using QUIC protocol or one of the other non-HTTPS is uses. If you upgrade to latest 3.5 Squid does some header pruning to prevent that where possible. And Squid 4.x has a feature to handle non-HTTPS and non-TLS protocols happening on port 443. Also, if the raw-IP on the CONNECT message happens not to have reverse-DNS matching your dstdomain list entries it will go through the proxy. That could open you to a lot of issues from your clients being infected or hijacked by scripts. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
