Re: [RFC] ssl-bump security bugs

On 04/10/2011 02:53 AM, Amos Jeffries wrote:

> It has become clear that ssl-bump opens several nasty security
> vulnerabilities to networks using it. Even putting aside the detail
> that it starts off life as a man-in-middle in the first place.

I agree that using ssl-bump can add more problems than just the
man-in-the-middle attack it is meant to be. I may be wrong, but I
suspect most of those problems are specific to how and where ssl-bump is
used. In other words, it should be possible to use ssl-bump more-or-less
securely (the man-in-the-middle attack aside) but not all ssl-bump uses
are secure. We should make secure use easier/better, of course.

> * ssl-bump traffic is marked as "accel". Even though it is not. Which
> causes http_port vhost, vport, defaultsite come into affect. Along with
> MISS and cache-control overrides not available in forward or intercept
> proxy.

This is discussed below.

> * It is conceivable that the tunnel may be legitimately made to another
> proxy. This proxy will answer the cache_object:// requests intended for
> that remote one.

The existing bumping code was never meant for cache hierarchies that
need tunnels to peers. If it works, great. If it does not, let's welcome
fixes. Meanwhile, we can claim that bumping such hierarchical tunnels
while ignoring requests for internal objects is not supported.

> * The decrypted requests are not re-encrypted when sent outbound. IIRC
> there were measure attempted to make this happen, but they seem to have
> been unsuccessful.

I hope the above is not universally true but specific to some setups. I
know that encryption worked correctly in the setups the implementation
was meant for, but perhaps something got broken. Are outgoing requests
encrypted in the setups where CONNECT requests are bumped?

> IMO these all stem from the lack of a distinct sslbump "mode" of
> operation and its leveraging accel mode flags to achieve some
> behaviours.

I agree that a special ssl-bump code may be needed in more places (e.g.,
your tunneling of internal requests to known peers seems like a good
candidate). I am not sure leveraging other modes in other places is
necessarily bad on its own, but perhaps the code is leveraging wrong
modes in wrong places.

> Some of these flaws can be fixed with ssl-bump specific code
> which will be dangerous to accel, and some of the accel behaviours are
> dangerous for intercepted traffic. But the way to identify bumped
> traffic being the accel flag makes this overly difficult.

I do not think we should identify bumped traffic using any of the
existing reverse proxy flags. When special handling of bumped traffic is
needed, we should use an "ssl-bumped" flag or test. Please note that
this does not mean that bumped traffic should not reuse some of the
existing reverse proxy flags/code at the same time, to trigger the right
handling outside of those special bump-only cases.

> Alex, Christos:
> can you please point out the reasons for using accel mode? which areas
> need to have (accel|sslbump) tests added when moving to a dedicated
> sslbump mode flag?

If I understand the question correctly, the motivation for using the
"reverse proxy" mode was that the ssl-bump, after the bumping, deals
with requests typical to a reverse proxy environment: Those requests are
sent to origin servers, not Squid.

I doubt there was ever a clear understanding of the difference between
various reverse-proxy flags. We probably used what seemed to work. Keep
in mind that the setting of those flags itself was changed/fixed (IIRC)
since the original ssl-bump code was written. It is possible that what
used to be the more-or-less right flag is no longer correct. It is also
quite possible that something other than "accel" would work much better,
but I am not quite sure we need a _new_ reverse proxy flag, orthogonal
to the existing ones (a new "ssl-bumped" flag may be a good idea though).

Finally, from the squid.conf and administrator point of view, ssl-bump
is used in at least two modes: interception (TCP hijacking) and forward
(CONNECT) proxy. I do not know whether both setups require the same
"reverse proxy" flag internally or not, but the latter setup essentially
becomes the former after the CONNECT request is "bumped".

To summarize, I think the best way forward may be:

1. Decide which existing reverse proxy flag(s) the ssl-bump code should
set. The decision can depend on whether we are bumping CONNECT requests
or intercepted connections. Use the right flag(s).

2a. Add a new "this connection (and transaction) was ssl-bumped" flag.

2b. Identify cases where bumped traffic needs special treatment.
Document current limitations/bugs on the wiki. Implement special
treatment code, using the new flag from (2a) as a trigger condition.
This may require several iterations, one special case at a time.

Thank you,

Alex.
Received on Mon Apr 11 2011 - 15:28:40 MDT