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
rouss...@measurement-factory.com 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.
