Re: [RFC] ssl-bump security bugs

On 04/11/2011 11:33 PM, Amos Jeffries wrote:
> 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.

Sorry if I misunderstood. Let me try to clarify. We have two options, at
least:

1. An ssl-bumped flag and nothing else. Used to correctly process all
requests and all special cases. Implies reverse proxy mode but is
exclusive to existing reverse proxy flags:

  if (accel) ...
  else if (intercepted) ...
  else if (sslBumped) ...

2. An ssl-bumped flag in addition to the right existing reverse proxy
flag(s). I know that the accel flag may not be the right one, but just
to illustrate this option:

  if (accel) {
     ...
     if (sslBumped) ...
     ...
  } else
  if (intercepted) {
     ...
     if (sslBumped) ...
     ...
  } else {
     ...
     if (sslBumped) ...
     ...
  }

I am not sure which approach is better.

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

Not exactly. In interception mode, Squid cannot fake the host name for
the certificate (i.e., the DynSslCert feature). However, (a) the
ssl-bump feature itself is working fine and (b) I suspect somebody will
eventually sponsor DynCert with interception support as we have several
companies waiting for somebody else to do it. Thus, I think we should
continue to support CONNECT and intercepted requests.

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

Agreed.

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

Sounds good to me.

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

Yes, but we may have to act based on partial information you already
have -- I have not heard any complaints about current limitations/bugs
that you discussed in your opening email (probably because our customers
use different setups) so you know more than I do when it comes to (2b).
Christos may have more insights based on his work with polishing and
porting the code.

HTH,

Alex.
Received on Tue Apr 12 2011 - 20:10:54 MDT