Re: [RFC] ssl-bump security bugs

On 05/05/2011 04:07 PM, Amos Jeffries wrote:
> 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.

OK.
  If there is not any problem I will commit this patch to trunk.

>
>
>
>>
>> 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 Thu May 05 2011 - 19:04:37 MDT