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@xxxxxxxxxxxxxxx/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
