Re: [RFC] Peek and Splice

On 1/02/2013 5:17 p.m., 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,

What problems and how would this be known?

> 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

Please avoid "ssl_bump2".

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

What about making "peek" a flag that can optionally prefix any of the
ssl_bump ACL actions...

   ssl_bump client-first foo !safeToPeek
   ssl_bump peek client-first foo
   ssl_bump server-first !safeToPeek
   ssl_bump peek server-first safeToBump
   ssl_bump none all

Overall the whole thing is getting complex and risks making a huge mess.
Time to reduce the options. This *is* a quazi-legal feature after all.

Amos
Received on Fri Feb 01 2013 - 06:25:04 MST