Re: filtering HTTPS/CONNECT (summary and continuation of discussion)

On 03/17/2012 07:59 AM, Marcus Kool wrote:
>
> Alex Rousskov wrote:
>> On 03/16/2012 03:05 PM, Marcus Kool wrote:
>>
>>> How do we go on from here?
>>
>> I recommend splitting this big problem into several smaller areas:
>>
>> Tunnel classification: As Henrik noted, Squid should wait for client (or
>> server!) handshake before starting the SSL handshake with the server.
>> Waiting for one of the sides to speak first (i.e., before Squid) allows
>> us to categorize the tunnel intent: SSL, HTTP, Other. This step is
>> critical for other projects below.
>
> Indeed this step is critical. Squid may not guess (wrongly) and
> unintentionally cause problems for applications that use CONNECT.

AFAICT, in many (most?) environments where SslBump is used, this is not
a huge deal because exceptions can be added for destinations that use
CONNECT for "non-HTTPS tunnels" and/or such destinations are prohibited
by the company internet usage policy anyway.

>> HTTP tunnel: Either go to tunnel.cc or process almost as a regular
>> request stream. Make the choice configurable.
>
> Not sure what you mean with "HTTP tunnel" (see below).

A stream of HTTP messages. This can happen either immediately after
CONNECT or after we decrypt SSL (with or without CONNECT). In fact, it
can even happen without CONNECT and SSL when we intercept [what we think
is] HTTP. On a conceptual level, my classification allows for tunnels
inside tunnels. Perhaps there are better terms to describe this, but the
key here is that Squid needs to make a decision at the beginning of each
tunnel.

>> SSL tunnel: Use bump-server-first. Add SNI forwarding support. If SSL
>> handshake with the server fails (there are many broken and weird servers
>> out there!), bump-server-first returns a secure error to the client. In
>> some cases, it may be better to re-tunnel the server end (without
>> bumping) or just close the client connection immediately. The former
>> requires serious coding effort; the latter does not, but both are pretty
>> straightforward. And make the choice configurable.

>> Other tunnel: When a non-HTTP traffic is encountered at the beginning of
>> a tunnel, switch to the tunneling mode or terminate both connections.
>> Make the choice configurable.

>> Filterable Other tunnels (bumped or not!): Define a protocol and/or API
>> to adapt tunnel.cc (or similar) I/O. Learn from ICAP mistakes. Implement
>> the client/hosting side of that protocol/API in Squid. 3rd parties will
>> implement the service/adapter sides.

> My point of view is "filter based" and I think that you could already
> read between the lines that I think that Squid should have it all to
> make all data filterable. Filtering is done for security; to block
> Skype but allow other safer chat and VOIP applications. To block
> HTTPS proxies, to prevent (accidental) leaks of documents to public
> document sharing sites. And of course to block viruses. Filtering
> is also done to force employees to pay more attention to their work
> and less to the sports comments on the internet, but filtering for
> security is more important. As the web changes and more servers
> use HTTPS and more applications use CONNECT, I think Squid should
> have it all to remain a fully featured and safe web proxy.

I do not think you need to spend time convincing others that many
proxies are deployed to analyze and block traffic and that, ideally, we
should correctly handle anything Squid may receive in common
environments. I bet that most, if not all, of us more or less agree.

>> Will you do any work on Squid itself or are you looking for a volunteer
>> on our end? If it is the former, would you like to create dedicated wiki
>> pages for those projects you are interested in and start nailing down
>> the details?
>
> I know very little of the internals of Squid and do not have the time
> to get to know the code well enough to make these types of changes.
>
> I am willing to write feature pages and assist in writing a detailed
> document
> for the new pipe filter protocol. ufdbGuard is GPLv2 and the
> new ICAP filter will also be GPLv2. The pipe filter module for the server
> will also be GPLv2 so that others (I am thinking of antivirus) can benefit
> from it.
>
>> If you are looking for volunteers to work on the Squid side, then I
>> would not recommend doing much on your end until you secure at least one
>> such person. Otherwise, you may end up with a filter that you cannot
>> attach to Squid.
>
> I do not want to appear to try to push the Squid team to do things.
> I know that you all are busy and that new features will have priorities
> and will be queued. I can only hope that the development team shares
> the same view that to remain a safe proxy, Squid needs the ability to
> filter *all* data.

I do not think there is a problem with a shared view here. There is a
problem with available development cycles to implement what you (and
others) want. Since you probably talk to many organizations that use
your filters, my personal recommendation is to find an organization that
needs this stuff badly enough to either dedicate a developer or sponsor
the required Squid changes.

> At this moment my #1 priority wish is that Squid 3.1.x or 3.2.x can
> be used with the sslBump feature turned on which does not break
> Skype and other applications using CONNECT. Will the new
> bump-server-first do this?

No, it will not by default. One would have to maintain a white list of
destinations that should not be bumped.

HTH,

Alex.
Received on Sat Mar 17 2012 - 17:10:16 MDT