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

On 03/17/2012 02:10 PM, Alex Rousskov wrote:
> 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.

I am astonished to see that banks and other top-500 companies which
spend fortunes on IT, allow SSH tunnels to go through their
web proxies and firewalls. Most of them do not use Squid so Squid
is not the only proxy with the security issue.
An unfiltered CONNECT (default for Squid) allows (SSH) tunnels.

SSH tunnels are simple to setup by a virus or a person with bad
intentions. ufdbGuard currently probes for SSH and can block it,
but has the disadvantage of doing various time-consuming probes
for various protocols that may trigger a security alert on servers
and prohibit further connections. Therefore, filtering the tunnel
is a much better way of prohibiting SSH or any other undesired
protocol.

I foresee a change. I foresee an increasing desire to be able to
filter everything because of the need to remove the existing holes
in security.

And please be not offended when I say that ACLs are not simple, and
managing ACLs for a list of applications that use CONNECT with an
application-specific protocol can be a large administrative effort.

And yes I admit, I am doing a plea to give the required changes to
filter *all* data a high priority.

[snip]

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

I never find clients who want to pay for functionality. They ask
for it or stay quiet and simply conclude after an evaluation that
the software does not meet the requirements. I think I envy you :-)

> HTH,
>
> Alex.

How does the development team work? Do you want me to enter
feature requests ?

Best regards,
Marcus
Received on Mon Mar 19 2012 - 15:06:57 MDT