Re: [RFC] ssl-bump security bugs

On 12/04/11 03:28, Alex Rousskov wrote:
> 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).

I'm not sure where yo got the new reverse proxy flag idea from. New
"bumped" flag was the proposal.

>
> 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".

I thought we had the interception case blocked due to lack of processing
the SSL details for domain name?

AFAIK, the two types of bump can share the same flag...
  * Both are received and require request processing through the
intercept/transparent pathways in client-side parsing.
  * Both require handling and processing via the reverse/accel pathways
on server-side.
  * Both need a CONNECT tunnel constructed on output to peers

Not sure of: which pathway through client-streams they both/each need.
I'm hoping nothing special.

I'm expecting to make a separate prepareBumpedURL() function [yuck! I
hate that whole prepare*() hack] to pull the URL domain name from the
right source (Host: header or SSL cert, avoiding the defaultsite=
parameter which gets involved today).

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

AFAICT to make the decisions in (1) we need the info in (2b) thus I
asked you and Christos for any details you have buried in your heads.
:)

Thank you for this reply. It has been helpful.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.12
   Beta testers wanted for 3.2.0.6