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

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.

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

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

Only after detection of SSL and after a successful SSL handshake Squid
can detect what happens inside the SSL-wrapped data stream.
Again Squid needs to monitor the server and the client and detect what
is inside the SSL-wrapped data stream: 'regular HTTP' or 'something else'.
When you refer to "HTTP tunnel", do you mean "SSL-wrapped HTTP" ?
Squid should switch to tunnel mode for an SSL-wrapped non-HTTP stream.

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

There are too many applications, and of course, a Squid admin wants to block
some and allow others. One switch for all applications seems not very
useful. Currently, only filters detect the various applications and can do
the selective blocking. Since not all Squid installation have an (ICAP) filter,
it is probably a good thing to have the switch anyway.

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

Also a "must have" to satisfy the idea that all data must be filterable.

> Did I miss any big cases?
>
> As you can see, all of the above are pretty much independent projects.
> Are _you_ interested in all or just some of them?

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.

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

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?

> Thank you,
>
> Alex.
Received on Sat Mar 17 2012 - 13:59:37 MDT