Re: [RFC] ssl-bump security bugs

From: Tsantilas Christos <chtsanti_at_users.sourceforge.net>
Date: Tue, 03 May 2011 17:02:54 +0300

I create the bug 3209.
Also I uploaded a first patch here.

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
Received on Tue May 03 2011 - 14:03:11 MDT

This archive was generated by hypermail 2.2.0 : Thu May 05 2011 - 12:00:03 MDT