[squid-dev] [RFC] Secure ICAP

Amos Jeffries squid3 at treenet.co.nz
Fri Feb 13 02:00:41 UTC 2015


On 13/02/2015 11:51 a.m., Alex Rousskov wrote:
> On 02/03/2015 07:02 PM, Amos Jeffries wrote:
> 
>> My plan for the Crypto-NG / libsecurity work already in audit was to
>> followup with a Security::Encryptor AsyncJob that could be passed the
>> Comm::Connection object from a newely opened connection plus the
>> Security::PeerOptions from squid.conf and initiate TLS/SSL on the
>> connection.
> 
> We already have PeerConnector -- an async job that encapsulates most of
> the security-related logic when it comes to connecting to other servers.
> It is used by TunnelStateData, FwdState, and PeerPoolMgr. I doubt you
> need another job that does the same.
> 

Is that class what you are proposing be used by ICAP? if not, then you
already have the answer why we need something slighty different.

Essentially yes, but its very tightly bound in design to how OpenSSL's
API operates.

> 
>> That model is reusable for cache_peer, DIRECT connections, ICAP, and any
>> other protocols which use the X-over-TLS protocol layering. Without any
>> major changes to the existing code - we just update the appropriate Comm
>> callback to kick off the new Security::Encryptor job once the server FD
>> is opened.
>>
>> I would like to push that update forward rather than anyone writing
>> another protocol-specific connection setup pathway. A good chunk of the
>> preparation work is already done, so the time to completion would also
>> be faster than a new project.
> 
> 
> Sure, we would gladly reuse anything available as long as we do not have
> to wait for it. AFAICT, if we use PeerConnector for Secure ICAP, and
> your NG changes go inside PeerConnector, then we will not be stepping on
> each other toes too much.

Okay.

The Encryptor I have sketched out so far can be a parent to
PeerConnector but without the SSL-Bump specific parts. I've been working
on figuring which bits are agnostic by making it PeerConnectors' parent
and abstracting upwards with an eye towards making Ssl::PeerConnector
the OpenSSL interface and a Tls::PeerConnector for the GnuTLS
alternative - with shared parts all in the NG Security::Encryptor.

Amos



More information about the squid-dev mailing list