Re: about https support for transparent proxy

Hi, Alex and Henrik

I'm sorry, there is a lack of explanation....

> It looks like you are working on a useful feature, but can you
>explain in more detail what your patch does? Why is the feature called
>SslConnect? Is it specific to tproxy environments or can it work with
>any transparent Squid? Does it work in combination with SslBump or are
>they mutually exclusive?

 - motivation

   http://wiki.squid-cache.org/Features/Tproxy4

   The above is still not supported https. I'd like to support https.
   In addition to above, the following configuration can support https
   with my patch.

   - squid configuration

     http_port 8443 tproxy sslConnect

   - iptables configuration

     iptables -t mangle -A PREROUTING -p tcp --dport 443 -j TPROXY --tproxy-mark
     0x1/0x1 --on-port 8443

> Do not work with SslBump I think. SslBump requires the CONNECT right?

Yes. SslBump is not relate to sslConnect, but I'm interested in SslBump.

>I guess it could be extended to respond with an SSL level error
>notification in these cases, but not sure it's worth the effort.

Right. I think that just comm_close() is simple...

To be honest, "https_port 8443 tproxy sslConnect" is better.
              ^^^^^^^^^^^^
But it's easier to hack http_port handling than https_port.

What do you think of my patch ?

Sincerely,

--
Mikio Kishi
On Tue, Jun 30, 2009 at 6:31 AM, Alex
Rousskov<rousskov_at_measurement-factory.com> wrote:
> On 06/29/2009 01:32 PM, Henrik Nordstrom wrote:
>> sön 2009-06-28 klockan 14:18 -0600 skrev Alex Rousskov:
>>
>>> Ok, but can you tell what the patch does? Forwards raw SSL connections
>>> to the next hop, as if Squid was a TCP proxy?
>>
>> Yes.
>>
>>>  Something else?
>>
>> Not really. But supports both forwarded mode and standalone (connecting
>> direct, or via a parent proxy).
>
> OK, I see.
>
>
>>>> Do not work with SslBump I think. SslBump requires the CONNECT right?
>>> I do not think so. In my tests, SslBump worked for WCCP-intercepted SSL
>>> connections.
>>
>> Are you sure that's SslBump, and not just https_port?
>
> You may be right. I thought I did change something in https_port when
> working on SslBump but I may be misremembering. If I did, it was
> certainly very little because most of the work was on the CONNECT
> requests handling. I do remember that I tested WCCP redirection of "port
> 443" traffic and it worked (with certificate warnings).
>
>> https_port works kind of in interception mode, if the certificate
>> warnings/errors is ignored.. has always been like that just not
>> documented very well.
>
> Agreed.
>
>> Note: SslBump (long term) could be made to work in interception mode
>> with modern browsers sending the requested hostname in the initial SSL
>> hello message.
>
> Thank you,
>
> Alex.
>
>
>