On 12/12/2014 02:31 AM, Yu-Hsuan Liao wrote: > I'm trying to using Squid 3.5's new feature peek-and-splice to bypass > Skype connection > I'm a little confused about ssl_bump steps, > the wiki says that > > peek Receive client (step SslBump1) or server (step SslBump2) > certificate while preserving the possibility of splicing the > connection. > My question is: does ssl_bump make decision to bump or splice connection > when Squid gets the ServerHello message? Squid makes the final decision to bump (or splice) the connection when the first ssl_bump bump (or ssl_bump splice) rule matches. Whether that final rule matches during step1, step2, or step3 depends on how you write your ssl_bump configuration (and on traffic). The peek/stare actions are for receiving information from client and server. Due to how SSL is designed, these actions usually have side effects as detailed on the wiki page: peeking usually implies eventual splicing and staring usually implies eventual bumping. Thus, you have to be careful how you get the information you need. > cos I found that Skype voice connection is first > > 1. client send Clien tHello > 2. server send Server Hello > > then began the skype data payload transmit(non-SSL format, not the > rest SSL handshake) > > so that I still got the "Error negotiating SSL connection on FD" > message in cache.log > > Does peek-and-splice function cover above situation, or I just > misunderstand the usage of ssl_bump peek? If Skype client and server Hello information is standard (supported by OpenSSL), then splicing connection should work at step1 or step2. For example, the following configurations should work: ssl_bump splice isSkype ... or ssl_bump peek all ssl_bump splice isSkype ... where "isSkype" is your custom ACL that matches Skype traffic. It is difficult to write such an ACL, as discussed below. If those Hello exchanges are not supported by OpenSSL, then you must splice at step1 without peeking: ssl_bump splice isSkype ... > acl skype_list dstdomain "skype_list" > ssl_bump peek skype_list > ssl_bump stare all This configuration will most likely not work because you are staring (which usually implies eventual bumping) at step2. You cannot bump a non-SSL connection. Moreover, I would be concerned about dstdomain matching at step1 where Squid has access to CONNECT (forward proxy) or TCP-level (intercepting proxy) information only and may be forced to do a reverse DNS lookup. The proper way to handle all this complexity is via automatic non-HTTP/non-SSL traffic bypass rather than hand-written rules that try to identify such traffic on a case-by-case basis. Unfortunately, the corresponding Squid feature got stuck in Squid Project review for a few months now. We have not given up on it though. HTH, Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
