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 DONT_VERIFY_PEER 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 - 07:36:07 MST
This archive was generated by hypermail 2.2.0 : Wed Dec 21 2011 - 12:00:03 MST