Re: [RFC] ssl-bump security bugs

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.

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

Regards,
  Christos
Received on Thu Apr 28 2011 - 17:26:23 MDT