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.
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..)
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?
Sean
On 21 December 2011 08:36, Sean Boran <sean_at_boran.com> wrote:
> According to the doc, sslproxy_flags only has only one other value
> NO_DEFAULT_CA.
> That doesn't seem of much use... it does recognise and refuse the
> expired cert though:
>
> 2011/12/21 07:30:01.269| Self signed certificate:
> /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=localhost.localdomain/emailAddress=root_at_localhost.localdomain
> 2011/12/21 07:30:01.269| confirming SSL error 18
> 2011/12/21 07:30:01.269| fwdNegotiateSSL: Error negotiating SSL
> connection on FD 29: error:14090086:SSL
> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
> (1/-1/0)
>
> But also refuses a well know bank:
> Self signed certificate in certificate chain:
> /1.3.6.1.4.1.311.60.2.1.3=CH/2.5.4.15=Private
> Organization/serialNumber=CH-020.3.906.075-9/C=CH/postalCode=8001/ST=Zuerich/L=Zuerich/streetAddress=Paradeplatz
> 8/O=Credit Suisse Group AG/CN=www.credit-suisse.com
> 2011/12/21 07:32:47.859| confirming SSL error 19
>
> And amazon:
> Unable to get local issuer certificate:
> /C=US/ST=Washington/L=Seattle/O=Amazon.com Inc./CN=www.amazon.com
>
> I had expected to mean "dont verify peer if it is the
> except acl".
> Hmm.
> Digging in the sources, in ssl/support.cc, there are more that two
> constants defined (I had just looked at the docs so far..). There is
> no actual VERIFY_PEER though.
>
> Looking at the sources it seems necessary that
> SSL_FLAG_DONT_VERIFY_PEER not be set if this is to be called:
> SSL_CTX_set_verify(sslContext, SSL_VERIFY_PEER ...);
>
> So, compiled the lastest HEAD and tried both VERIFY_CRL,
> VERIFY_CRL_ALL which would presumably have done some additional CRL
> checking, but the example sites above fail on that too:
>
> Unable to get certificate CRL:
> /C=US/ST=Washington/L=Seattle/O=Amazon.com Inc./CN=www.amazon.com
>
> Which would look like its requires the existence of a CRL for each destination?
> Tried setting capath to an empty directory, but it probably requires
> some standard CRLs.
>
> Squid pull its standard CA list from openssl (/etc/ssl/certs ?), but
> should just accept empty crl lists if there are none? Setting
> capath=/etc/ssl/certs and crlfile=/emptyfile does not help.
>
> I muust still be missing something..
>
>
> As regards The Measurement Factory, their website looks interesting,
> but I dont see any relevant references. Is there a discussion or
> ticket on what they are planning and how to contact them ? Should I
> ask on squid-dev?
>
> Thanks,
>
> Sean
>
>
> On 21 December 2011 01:02, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
>> On 21/12/2011 3:34 a.m., Sean Boran wrote:
>>>
>>> Hi,
>>>
>>> sslbump allows me to interrupts ssl connections and run an AV check on
>>> them.
>>> It generates a certs for the target domain (via sslcrtd), so that the
>>> users browser sees a server cert signed by the proxy.
>>>
>>> If the target domain has a certificate that is expired, or it not
>>> signed by a recognised CA, its important that the lack of trust is
>>> communicated to the end user.
>>>
>>> Example, on connecting direct (not via a proxy) to
>>> https://wiki.squid-cache.org the certificated presented is expired 2
>>> years ago and not signed by known CA .
>>> Noext on connecting via a sslbump proxy (v3.2.0.14), the proxy creates
>>> a valid cert for wiki.squid-cache.org and in the user's browsers it
>>> looks like wiki.squid-cache.org has a valid cert signed by the proxy.
>>>
>>> So my question is:
>>> What ssl_bump settings would allow the proxy to handle such
>>> destinations with expired or non trusted sites by, for example:
>>> a) Not bumping the connection but piping it through to the user
>>> unchanged, so the user browser notices the invalid certs?
>>> b) Refuses the connection with a message to the user, if the
>>> destination is not on an allowed ACL of exceptions.
>>
>>
>> Pretty much. The Measurement Factory has a project underway to fix this
>> limitation.
>> Please contact Alex about sponsoring their work to make it happen faster, or
>> get access to the experimental code.
>>
>>
>>>
>>> Looking at squid.conf, there is sslproxy_flags, sslproxy_cert_error
>>> # TAG: sslproxy_flags
>>> # DONT_VERIFY_PEER Accept certificates that fail
>>> verification.
>>> # NO_DEFAULT_CA Don't use the default CA list built in
>>> to OpenSSL.
>>> # TAG: sslproxy_cert_error
>>> # Use this ACL to bypass server certificate validation errors.
>>>
>>> So, the following config would then implement scenario b) above?
>>>
>>> # Verify destinations: yes, but allow exceptions
>>> sslproxy_flags DONT_VERIFY_PEER
>>> #sslproxy_flags none
>>> # ignore Certs with certain cites
>>> acl TrustedName url_regex ^https://badcerts.example.com/
>>> sslproxy_cert_error allow TrustedName
>>> sslproxy_cert_error deny all
>>>
>>> ==> But then, why does it not throw an error when connecting to
>>> https://wiki.squid-cache.org ?
>>
>>
>> You configured not to verify, therefore the error is not noticed and cannot
>> trigger any action.
>>
>> Why no output is displayed you will have to ask the OpenSSL people. There
>> are a few places in their API like this where errors are silently dropped
>> and seemingly no way is provided to check for them externally (ie from
>> Squid).
>>
>> Amos
Received on Wed Dec 21 2011 - 09:16:50 MST
This archive was generated by hypermail 2.2.0 : Wed Dec 21 2011 - 12:00:03 MST