On 6/02/2015 6:10 p.m., Luis Miguel Silva wrote: > Dear all, > > I recently compiled squid-3.4.9 with ssl-bump support and, although it is > working for the most part, I'm having some issues accessing some websites. > > The behavior is REALLY weird so I'm going to try and describe it the best I > can: > - If i access https://www.google.com/ in Chrome, I could see that it was > processing my certificate MOST of the times... > *screenshot here*: http://imgur.com/JsNiqDL,Ned5zAU,nJjRPtg > - some other times, it seemed to bypass my proxy altogether and I finally > figured out it was because Chrome will try to access QUIC enabled websites > using that protocol, so it would bypass my firewall redirect rules! I > believe I now have solved this by blocking FORWARDING traffic on port 443 > udp... reply_header_access Alternate-Protocol deny all This was added by default in 3.5. Your report now is the final straw for me I'm backporting it to 3.4 now for adding in the next security release. NOTE that this firewall bypass behaviour it seems does not qualify for a CVE security rating because it is an intentional *designed* behaviour of Chrome using a designed feature of HTTP. > - the weird thing is that, if I then try and access https://gmail.com, I > get a certificate error: > *screenshot here*: http://imgur.com/JsNiqDL,Ned5zAU,nJjRPtg#1 Because with HTTPS traffic to a proxy the proxy sets up the tunnel using a) CONNECT request, or b) intercepted port 443 - in both cases encryption handling happens before any server response message with QUIC headers gets involved. > - ...though, sometimes, I can access https://mail.gmail.com/ just fine > (without any certificate errors), but stop being able to as soon as I try > to access https://gmail.com/ and the browser complains about the > certificate. The google TLS certificate I've read were issued with the CN label "mail.google.com" plus wildcard for other G* domains. This might be related to that behaviour if the main CN is mimic'd but the wildcards not. > -- and, according to my tests, I can access it from firefox just fine MOST > of the times: > *screenshot here*: http://imgur.com/JsNiqDL,Ned5zAU,nJjRPtg#2 > -- though I have also seen situations where Firefox also complains about a > certificate error when connecting to gmail.com > - and, although I cannot reproduce it 100% of the times, sometimes, even > though I have my iptables redirect rules ON, the browser still seems to > "connect direct" (or, at least, it shows it has the original certificate)! > -- like I said, at first, I was able to trace this back to QUIC in Chrome > but...I'm currently blocking traffic on port 443 udp so I don't know what's > happening here (does it use different ports?!) Very possible. Since the port is delivered in the Alternate-Protocol header they can change it anytime. I've see both ports 80 and 443 in use. Blocking the reply header is the way to be most sure of disabling. > > So, here are *my questions*: > - why am I able to successfully ssl-bump https://www.google.com but not > https://gmail.com/ > - why does the Chrome freakout about gmail but not Firefox? Many reasons. I point at HSTS - which is a collection of certificate management methods and protocol bits they use to perform things like cert pinning, side channel verification, etc. At the base of it TLS was designed from the ground up to be a security protocol that prevented anybody from hijacking it (like SSL-bump does), or at least shout loudly to the endpoints if someone does. Only terribly bad mis-use or security flaws in the protocol allow things like SSL-Bump to work in the first place. You all have just been lucky so far that so the Trusted CA system is a big flaw and mis-use of the protocol is rampant. Google and friends are fighting to fix those flaws. Whenever they succeed at closing one flaw the hjacking using it "stops working". > - Is there a way to fix it OR, at least, to bypass it? (I tried creating an > ACL for this and allowing direct traffic but it didn't seem to work...) > -- can we make the connection go direct when ssl certificate errors are > detected? Lets be clear; *you* are the brokenness here, *you* are the attacker. ... when SSL-Bump "dont work" it means the security *is* working. What you are looking for is not a "fix". It is another security flaw so you can break their now-improved encryption again. That should tell you what the answer is. > - and has anyone else seen this problem where the browser seems to use the > original certificate, even though I'm redirecting traffic to Squid? > > Not sure if this is relevant, but here are some ssl errors I caught on my > cache.log file: > root@server:/var/log/squid3# tail cache.log > 2015/02/05 21:47:52 kid1| clientNegotiateSSL: Error negotiating SSL > connection on FD 30: Closed by client > 2015/02/05 21:48:36 kid1| clientNegotiateSSL: Error negotiating SSL > connection on FD 96: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 > alert unknown ca (1/0) > By the way, here's how I generated my certificate: > openssl req -new -newkey rsa:1024 -days 365 -nodes -x509 -keyout myCA.pem > -out myCA.pem > openssl x509 -in myCA.pem -outform DER -out certificate.der > (note: myCA.pem is the certificate that squid is using and certificate.der > is the one I've been installing on the client computers) > > And here's what my current squid.conf looks like: > root@server:/etc/squid3/ssl_cert# cat /etc/squid3/squid.conf > #Access Lists > acl home_network src 192.168.200.0/24 > > #Ports allowed through Squid > acl Safe_ports port 80 #http > acl Safe_ports port 443 #https > acl SSL_ports port 443 > acl SSL method CONNECT > acl CONNECT method CONNECT > > #allow/deny > http_access allow home_network > http_access deny !Safe_ports > http_access deny CONNECT !SSL_ports > http_access deny all > Them security controls are not doing much. Its for very good reaons that we publish this particular order with a big notice about where to put your access policy rules: http_access deny !Safe_ports http_access deny CONNECT !SSL_ports ## PUT YOUR STUFF HERE http_access allow home_network http_access deny all > http_port 3128 > http_port 3129 intercept > https_port 3130 intercept ssl-bump generate-host-certificates=on > dynamic_cert_mem_cache_size=4MB cert=/etc/squid3/ssl_cert/myCA.pem > acl broken_sites dstdomain .gmail.com > ssl_bump none localhost > ssl_bump none broken_sites > ssl_bump server-first all > sslcrtd_program /usr/lib/squid3/ssl_crtd -s > /usr/share/squid3/var/lib/ssl_db -M 4MB > sslcrtd_children 5 > > #caching directory > cache_dir ufs /var/spool/squid3 1024 16 128 > cache_mem 1024 MB > > #refresh patterns for caching static files > refresh_pattern ^ftp: 1440 20% 10080 > refresh_pattern ^gopher: 1440 0% 1440 > refresh_pattern -i \.(gif|png|jpg|jpeg|ico)$ 10080 90% 43200 > override-expire ignore-no-cache ignore-no-store ignore-private > refresh_pattern -i \.(iso|avi|wav|mp3|mp4|mpeg|swf|flv|x-flv)$ 43200 90% > 432000 override-expire ignore-no-cache ignore-no-store ignore-private > refresh_pattern -i \.(deb|rpm|exe|zip|tar|tgz|ram|rar|bin|ppt|doc|tiff)$ > 10080 90% 43200 override-expire ignore-no-cache ignore-no-store > ignore-private > refresh_pattern -i \.index.(html|htm)$ 0 40% 10080 > refresh_pattern -i \.(html|htm|css|js)$ 1440 40% 40320 > refresh_pattern . 0 40% 40320 > > dns_nameservers 8.8.8.8 > > #rewrite program > redirect_program /etc/squid3/filter.php > root@server:/etc/squid3/ssl_cert# > > Thanks in advance, > Luis > HTH Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
