On 29/09/2016 11:27 a.m., Eliezer Croitoru wrote: > I am also testing this issue and I have the next settings: > acl DiscoverSNIHost at_step SslBump1 > acl NoSSLIntercept ssl::server_name_regex -i "/etc/squid/url.nobump" > ssl_bump splice NoSSLIntercept > ssl_bump peek DiscoverSNIHost > ssl_bump bump all > sslcrtd_program /usr/lib/squid/ssl_crtd -s /var/squid/ssl -M 4MB > sslcrtd_children 10 > read_ahead_gap 64 MB > sslproxy_cert_error allow all > tls_outgoing_options flags=DONT_VERIFY_PEER > acl foreignProtocol squid_error ERR_PROTOCOL_UNKNOWN ERR_TOO_BIG > on_unsupported_protocol tunnel foreignProtocol > > (Which is not recommended for production as is!!!) > > Now the "/etc/squid/url.nobump" file contains: > # WU (Squid 3.5.x and above with SSL Bump) > # Only this sites must be spliced. > update\.microsoft\.com$ > update\.microsoft\.com\.akadns\.net$ > v10\.vortex\-win\.data\.microsoft.com$ > settings\-win\.data\.microsoft\.com$ > # The next are trusted SKYPE addresses > a\.config\.skype\.com$ > pipe\.skype\.com$ > mail\.rimon\.net\.il$ > w[0-9]+\.web\.whatsapp\.com$ > \.web\.whatsapp\.com$ > web\.whatsapp\.com$ > ##END OF NO BUMP DOMAINS. > > And squid 4.0.14 doesn't tunnel the requests. > The above is with: > http_port 3128 > http_port 13128 intercept > https_port 13129 intercept ssl-bump \ > cert=/etc/squid/ssl_cert/myCA.pem \ > generate-host-certificates=on dynamic_cert_mem_cache_size=4MB > > On the 443 intercept port. > Access log output: > 1475100891.636 000445 192.168.10.112 NONE/200 0 CONNECT 158.85.224.178:443 - ORIGINAL_DST/158.85.224.178 - 52:54:00:bc:9f:73 > 1475100908.469 000223 192.168.10.112 TCP_MISS/200 508 GET https://web.whatsapp.com/status.json - ORIGINAL_DST/31.13.90.51 text/json 52:54:00:bc:9f:73 > 1475100952.107 000445 192.168.10.112 NONE/200 0 CONNECT 158.85.224.178:443 - ORIGINAL_DST/158.85.224.178 - 52:54:00:bc:9f:73 > 1475100968.832 000191 192.168.10.112 NONE/200 0 CONNECT 216.58.214.110:443 - ORIGINAL_DST/216.58.214.110 - 52:54:00:bc:9f:73 > 1475100968.984 000199 192.168.10.112 NONE/200 0 CONNECT 172.217.22.14:443 - ORIGINAL_DST/172.217.22.14 - 52:54:00:bc:9f:73 > 1475101012.572 000447 192.168.10.112 NONE/200 0 CONNECT 158.85.224.178:443 - ORIGINAL_DST/158.85.224.178 - 52:54:00:bc:9f:73 > 1475101033.232 000621 192.168.10.112 NONE/200 0 CONNECT 31.13.66.49:443 - ORIGINAL_DST/31.13.66.49 - 52:54:00:bc:9f:73 > 1475101034.470 001224 192.168.10.112 TCP_MISS/200 512 GET https://web.whatsapp.com/status.json - ORIGINAL_DST/31.13.66.49 text/json 52:54:00:bc:9f:73 > 1475101073.039 000446 192.168.10.112 NONE/200 0 CONNECT 158.85.224.178:443 - ORIGINAL_DST/158.85.224.178 - 52:54:00:bc:9f:73 > 1475101133.502 000448 192.168.10.112 NONE/200 0 CONNECT 158.85.224.178:443 - ORIGINAL_DST/158.85.224.178 - 52:54:00:bc:9f:73 > > Now the issue is more then just this since I cannot see any logs about the websocket connections ie to the domains: > w3.web.whatsapp.com > They might be in the ones with raw-IP in NONE/200 lines. Since server_name_regex matches against the TLS-cert details which do not necessarily get logged as a URL domain name when splice is done. The SNI _should_ be made the CONNECT URI domain. But when it matches the server cert altSubjectName that is definitely not a client requested value. > and couple other similar. > > What I did until now is to bypass specific domains IP addresses using ipset+iptables. > I believe that squid can do much better then it's doing now. Can you get a packet dump to see what its TLS handshake details actually are? both client and server sides of Squid. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
