Re: [squid-users] Certificate server validation

Hi Alex

>> 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).
>
>

Apologies for the slow reply - this is REALLY interesting

At the moment I'm playing with ndpi (part of ntop), which does some
simple parsing of the raw tcp packets to try and dig out the certificate
cname. I'm fairly sure a determined attacker could get past this, but
this is probably acceptable for it's main requirement

My situation is that I need to restrict access to certain classes of
connection. Mostly we have a situation where the bandwidth costs are
expensive the user themselves is volunteering to be restricted so that
they don't spend on connections they don't value. So for example they
will wish to restrict antivirus scanner updates, windows updates, Skype
registrations, IOS push, etc.

So users request a specific firewall profile to be applied, but that
increasingly everything looks like http/https these days... So we desire
to standardise on one method to police, log and restrict http protocols
and ideally that would be squid.

So yes, Peek with restrict (and a rather abrupt disconnect) would be
superb for our purposes. Will wait and watch!

Cheers

Ed w
Received on Wed Feb 27 2013 - 19:05:50 MST