Re: [RFC] ssl-bump security bugs

On 04/29/2011 08:30 AM, Amos Jeffries wrote:
> On 29/04/11 05:26, Tsantilas Christos wrote:
>> On 04/12/2011 11:10 PM, Alex Rousskov wrote:
>>> 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:
>>>>>
>> .....
>>>>>> * 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.
>>
>> Do we have any such report? Which is the used configuration?
>> I did some tests here, and also I tried to find such cases but I did not
>> found. The traffic in my tests always re-encrypted before sent.
>>
>
> I have two users mention replication of this in squid-users.
>
> The replicated case seems to be:
> http_port ... ssl-bump
> cache_peer ... parent ...
> always_direct deny all

Yep this is true.
I think we should consider it as a bug.
What I am actually getting is the following:

<=https==> [proxy] <===http==>[proxy2]<==https==>

The easier solution is to add a check in FwdState::connectStart() in
forward.cc file:
  if (fs->_peer && request->protocol == AnyP::PROTO_HTTPS) {
    anErr = errorCon();
    fail(enErr);
    return;
}
The above will just disable any ssl-bumped connection through any parent

Also we should define if the "allow-direct" http-port options will have
any effect in ssl-bump...

The ideal I think is to use "CONNECT ..." when connecting through a
parent proxy. But this is requires more development, I do not know if it
is required and if we need it...

>
> NP: the ssl-bump features page says "always_direct allow all" is
> required. Simply removing that line to allow Squid to send to a parent
> peer causes the behaviour seen.
>
>>
>>>>> ...
>>>>>
>>>>>> 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) ...
>>
>> maybe it make sense...
>> Looking the code I can not find many advantages with using the accel
>> flag for ssl-bumped connections. But it requires more study, maybe I am
>> loosing something...
>> Moreover the ssl-bumped requests have more similarities with the
>> intercepted requests than the accelerated....
>>
>>
>>>
>>>
>>> 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.
>
> Both look the same to me. #1 is what we need now. #2 is extended to
> handle bumping inside intercepted traffic. That bit can go in when we
> have the cert sniffing.
>
> Amos
Received on Fri Apr 29 2011 - 08:33:19 MDT