Re: [RFC] Peek and Splice

On 02/01/2013 02:17 AM, Alex Rousskov wrote:
> Hello,
>
> Many SslBump deployments try to minimize potential damage by _not_
> bumping sites unless the local policy demands it. Unfortunately, this
> decision must currently be made based on very limited information: A
> typical HTTP CONNECT request does not contain many details and
> intercepted TCP connections are even worse.
>
> We would like to give admins a way to make bumping decision later in the
> process, when the SSL server certificate is available (or when it
> becomes clear that we are not dealing with an SSL connection at all!).
> The project is called Peek and Splice.
>
> The idea is to peek at the SSL client Hello message (if any), send a
> similar (to the extent possible) Hello message to the SSL server, peek
> at the SSL server Hello message, and then decide whether to bump. If the
> decision is _not_ to bump, the server Hello message is forwarded to the
> client and the two TCP connections are spliced at TCP level, with Squid
> shoveling TCP bytes back and forth without any decryption.
>
> If we succeed, the project will also pave the way for SSL SNI support
> because Squid will be able to send client SNI info to the SSL server,
> something that cannot be done today without modifying OpenSSL.
>
> I will not bore you with low-level details, but we think there is a good
> chance that Peek and Splice is possible to implement without OpenSSL
> modifications. In short, we plan using OpenSSL BIO level to prevent
> OpenSSL from prematurely negotiating secure connections on behalf of
> Squid (before Squid decides whether to bump or splice). We have started
> writing BIO code, and basic pieces appear to work, but the major
> challenges are still ahead of us so the whole effort might still fail.
>
>
> There are a few high-level things in this project that are not clear to
> me. I hope you can help find the best solutions:
>
> 1. Should other bumping modes switch to using SSL BIO that is required
> for Peek and Splice? Pros: Supporting one low-level SSL I/O model keeps
> code simpler. Cons: Compared to OpenSSL native implementation, our BIO
> code will probably add overheads (not to mention bugs). Is overall code
> simplification worth adding those overheads and dangers?
>
>
> 2. How to configure two ssl_bump decisions per transaction?
>
> When Peek and Splice is known to cause problems, the admin should be
> able to disable peeking using CONNECT/TCP level info alone. Thus, we
> probably have to keep the current ssl_bump option. We can add a "peek"
> action that will tell Squid to enable Peek and Slice: Peek at the
> certificates without immediately bumping the client or server connection
> (the current code does bump one or the other immediately).
>
> However, many (most?) bumping decisions should be done when server
> certificate is known -- the whole point behind Peek and Splice. We can
> add ssl_bump2 or ssl_bump_peeked that will be applied to peeked
> transactions only:
>
> ssl_bump peek safeToPeek
> ssl_bump none all
>
> ssl_bump_peeked server-first safeToBump
> ssl_bump_peeked splice all
>
>
> Is that the best configuration approach, or am I missing a more elegant
> solution?
>
>
> If there are any other Peek and Splice suggestions or concerns, please
> let me know.
>
>
> Thank you,
>
> Alex.

This Peek&Splice feature will make ssl_bump a useful feature since
without Peek&Splice ssl_bump aborts all non-SSL CONNECTS from Skype
and other applications, so the user community will certainly welcome this.

Currently Squid only sends to the ICAP server a
    REQMOD CONNECT www.example.com:443 (without content)
and there is never a RESPMOD.
I, as author of ufdbGuard and the (yet unpublished) new ICAP content filter,
would welcome very much if the data of the peeks (client and server)
is encapsulated into ICAP requests for the obvious purpose of
content filtering.

Thanks

Marcus
Received on Fri Feb 01 2013 - 13:47:11 MST