Re: [RFC] ssl-bump security bugs

On 04/05/11 02:02, Tsantilas Christos wrote:
> I create the bug 3209.
> Also I uploaded a first patch here.
>

Found the original discussion again:
http://bugs.squid-cache.org/show_bug.cgi?id=2314

That old bug covers the full feature redesign to both do SSL properly to
SSL marked peers and make CONNECT tunnels through non-SSL peers.

Your new one can be left separate for now to track the smaller
enhancement of blocking the info leakage.

>
> On 04/29/2011 06:52 PM, Amos Jeffries wrote:
>> On 29/04/11 20:33, Tsantilas Christos wrote:
>>> 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==>
>>>
>>
>> Yes that appears to be it. The problems being that a) proxy2 may not
>> have OpenSSL feature built in to re-crypt, and b) that the middle
>> channel is cleartext
>>
>>>
>>> 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
>>
>> As a short-term it may be okay. I don't see that working well with
>> normal proxied https:// URL requests, but those seem relatively rare.
>>
>>>
>>> Also we should define if the "allow-direct" http-port options will have
>>> any effect in ssl-bump...
>>
>> allow-direct being an accelerator mode option I think it will be
>> irrelevant once ssl-bump mode is created.
>>
>> Since always_direct is documented as recommended, allow-direct behaviour
>> would seem to be implied for ssl-bump mode.
>>
>>>
>>> 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...
>>
>> Yes. I imagine the MITM crowd doing interception of LAN traffic from
>> local workmates and funneling up to a corporate proxy will want that.
>>
>> 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