Re: [RFC] ssl-bump security bugs

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

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

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