On 21/12/2011 10:16 p.m., Sean Boran wrote:
So, as a test I set SSL_FLAG_DONT_VERIFY_PEER, then modified ssl/support.cc sslCreateClientContext() to ignore SSL_FLAG_DONT_VERIFY_PEER to that it would always verify. Then my three test cases woks just fine. The unsigned cert is refused (although with a not very precise error message to the user), and the two valid ones work.
So you hard-code Squid to behave as if the flag was not set. How is that different to not setting it in the first place?
sslproxy_* directives configure what Squid does on SSL connections to servers.
Another quick hack: ssl_verify_cb(): disabled domain checking (so that amazon.com worked with its insufficient www.amazon.com cert. (Setting sslflags=DONT_VERIFY_DOMAIN on the http_port config line di not work..)
Makes sense, I dont believe client certificates contain a domain name. Although they may include the TCP level details of the client as equivalents.
http_port sslflags= are configuring what to verify on received client certificates.
SSL has no functionality for the server to tell the remote client what not to verify. That would defeat the entire purpose of certificates.
Obviously the above hacking is not the proper solution though, should I move this conversation to the squid-dev list? What would you suggest as the next step Amos?
Yes please move this to squid-dev. Christos and Alex who authored the bump feature do not often read this mailing list regularly.
Amos
