It took me a while and I hope that I will be able to get the dumps this week. I started working on an example of ebtables level traffic redirection towards the squid machine. The scenario should be a good example for embedded devices which operates mostly food in the bridge level rather then the CPU and iptables level. Eliezer ---- Eliezer Croitoru Linux System Administrator Mobile: +972-5-28704261 Email: eliezer@xxxxxxxxxxxx -----Original Message----- From: squid-users [mailto:squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Amos Jeffries Sent: Thursday, September 29, 2016 07:16 To: squid-users@xxxxxxxxxxxxxxxxxxxxx Subject: Re: Web Whatsapp, Dropbox... problem 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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
