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
