Re: about https support for transparent proxy

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Fri, 03 Jul 2009 10:25:54 -0600

On 07/03/2009 08:48 AM, Mikio Kishi wrote:
> 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.

Please rename "sslConnect" in squid.conf and in source code to
"sslTunnel" or, if you do not plan on doing anything SSL-specific, to
"tcpTunnel". Other names may work better than my suggestion, but I think
we should avoid the word "connect" that can be easily confused with HTTP
CONNECT requests.

Please see my earlier email for other comments. I also agree with Henrik
that tcp_port may be a good idea because your code does not work on HTTP
level, but I understand that it is a bigger change.

Thank you,

Alex.

>> 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.
>>
>>
>>
Received on Fri Jul 03 2009 - 16:26:08 MDT

This archive was generated by hypermail 2.2.0 : Fri Jul 10 2009 - 12:00:04 MDT