HI Alex, Excuse me because I'm not native to English. And thanks your good points. I changed debug to ALL,9 that's huge, but I found what's wrong with me: 2013/12/11 13:50:06.914 kid1| Acl.cc(156) matches: checking bypass-ssl 2013/12/11 13:50:06.914 kid1| DomainData.cc(131) match: aclMatchDomainList: checking 'www.website.com' 2013/12/11 13:50:06.914 kid1| DomainData.cc(135) match: aclMatchDomainList: 'www.website.com' NOT found And looked back to my config, I should use dstdom_regex instead of dstdomain if I want to use wildcard here. Again, thanks for your value comment. ~Neddy, On Wed, Dec 11, 2013 at 12:50 PM, Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > On 12/10/2013 09:13 PM, Neddy, NH. Nam wrote: >> Hi, >> >> I've installed squid 3.4 STABLE for forward proxying with ssl-bump >> (followed Squid Wiki). Everything is fine until client visit https >> pages which have bad certificates (ie. seft signed). >> >> My configure to tell Squid bypass those: >> >> acl bypass-ssl dstdomain *.website.com >> >> ssl_bump none bypass-ssl >> ssl_bump server-first all > > > OK, but please note that the above only works if > > a) The CONNECT request is using a domain name; > > or > > b) The CONNECT request is using an IP address. Squid can get a domain > name by doing a reverse DNS lookup on that IP address _and_ the result > of that reverse lookup is the domain name you expect and not some > internal/irrelevant/different domain. > > In many cases, neither (a) nor (b) are true. > > >> The result is Squid bypasses ACL but still do ssl-bump, and client >> still receive generated cert from Squid. > > Sorry, the above sentence is unclear, especially the "Squid bypasses > ACL" part. You may want to rephrase. > > >> I've expected ssl_bump will not terminate ssl by those >> directive, If so, what should I do? > > Yes, if bypass-ssl matches, Squid should not terminate SSL. > > > Here is the suggested troubleshooting plan. > > 1) Collect the CONNECT request that violates your expectations. Use > "debug_options ALL,2" in squid.conf, packet capture, custom access.log, > whatever works best for you. Once you have the request, you can repeat > it if needed, in isolation, using tools like nc, curl, wget, etc. > > 2) Determine whether that CONNECT request is using an IP address for the > tunnel destination. If CONNECT is using a domain name, should the > bypass-ssl match that domain? If bypass-ssl should match but does not, > report a bug. > > 3) If CONNECT request is using an IP address, perform a reverse DNS > lookup yourself, using the same DNS resolver that Squid is using. "Dig" > or even "host" command may be used for that in most cases. Do you get a > DNS answer with a domain name? Should that domain name match your > bypass-ssl ACL? If bypass-ssl should match in this case but does not, > report a bug. > > The above plan does not cover all possibilities, but is a good start. > > If you need to report a bug, change debug_options to ALL,9; reproduce > the problem using a single request (with no other traffic going through > Squid); and post the compressed cache.log. > > > Good luck, > > Alex. >
