Re: [squid-users] Certificate server validation

On 02/09/2013 11:58 AM, Ed W wrote:
> On 20/01/2013 01:24, Amos Jeffries wrote:
>> On 19/01/2013 3:37 a.m., vincent viard wrote:
>>> I ask you about the feasibility of achieving an validation server
>>> certificates used during session establishment SSL/TLS in HTTPS at the
>>> level of SQUID proxy ?

>>> The idea is not to break the SSL session with a man-in-the-middle (ex.
>>> SSLBump), but to authenticate (and to authorize) the target with a
>>> white or black list of CAs. In other words, realize with Squid, the
>>> first validation of the SSL handshake logically made by the client
>>> browser on the certificate of server.

>> Please see http://wiki.squid-cache.org/Features/SslServerCertValidator
>>
>> This feature is merged and will be in 3.4 series when it is released.
>> To use it now you need to build the 3.HEAD Squid sources.

> Can squid handle a slightly simpler case where we want to restrict
> CONNECT access to servers which meet/fail to match a certain SSL cname?
> eg I want to block facebook access, but without sslbump, so I allow SSL
> proxying, but deny connections to servers with an SSL cname *.facebook.com?

If your blocking decision is based on information coming from the HTTP
CONNECT request alone, then you can block CONNECT requests using regular
http_access rules. For example, you can block CONNECT requests for a
given origin server name or a given IP address. The only caveat I am
aware of is that most browsers will not display Squid's error page in
this case because browsers cannot separate secure server response
context from insecure proxy CONNECT response context (and there have
been attacks based on the lack of context separation before browsers
stopped displaying CONNECT responses).

If your blocking decision is based on information coming from the SSL
server certificate itself, then you have to bump the transaction for
Squid to see that certificate. Without bumping, Squid only sees CONNECT
headers and raw opaque-to-Squid TCP payload bytes. For example, the
SslServerCertValidator feature that Amos recommended (thanks Amos!)
requires bumping the transaction.

SSL server certificate is not available at HTTP CONNECT inspection time.
You can hack a helper script that will connect to the server using the
CONNECT address, receive an SSL certificate, terminate the connection,
and tell Squid what the certificate was, but doing so is "bad" for
servers, so I would expect that some of them will eventually complain to
your ISP, block your source IPs, or even feed your helper with bogus
info. It will also not work with servers using SNI.

FWIW, we are working on a Peek and Splice feature that allows decisions
based on server SSL certificate without bumping the connection, but we
still have to solve a few difficult problems before I can be certain
that it is doable at all:
    http://www.mail-archive.com/squid-dev@squid-cache.org/msg19574.html

Finally, I think it is technically possible to peek at the certificate
with no intention of bumping the connection (but with the intention of
possibly terminating it). I am not aware of anybody working on this, but
the Peek and Splice feature mentioned above will provide this
functionality as a side effect.

However, please note that without bumping, you still will not be able to
serve an error page to the blocked user because the browser will expect
to communicate with the [secure] origin server, not Squid (the browser
already sent its SSL Hello request).

HTH,

Alex.
Received on Tue Feb 12 2013 - 01:18:18 MST