Re: about https support for transparent proxy

Alex Rousskov wrote:
> 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 still don't quite see how much of the internal traffic Squid gets
access to with this.

Please definitely call it sslTunnnel and add some detailed documentation
about what the traffic does when inside Squid. ie does it get igored and
shoved back out again at eariest convenience, or passed through all of
Squids normal http_port traffic controls, shaping, rewriting and
forwarding mechanisms?

Also Please correct this:

+ // set url
+ int url_sz = 32 + Config.appendDomainLen;
+ http->uri = (char *)xcalloc(url_sz, 1);
+ snprintf(http->uri, url_sz, "%s:%d",
+ http->getConn()->me.NtoA(ntoabuf,MAX_IPSTRLEN),
+ http->getConn()->me.GetPort());

MAX_IPSTRLEN is greater then 32 all by itself. Things go badly wrong
when Config.appendDomainLen is less than the difference. Also the
IpAddress ToURL() call does correct address:port creation for use in
URLs like this.

Please use:
   http->uri = (char *)xcalloc(MAX_IPSTRLEN, 1);
   http->getConn()->me.ToURL(http->uri,MAX_IPSTRLEN)

>
>>> 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.
>>>
>>>
>>>
>

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE6 or 3.0.STABLE16
   Current Beta Squid 3.1.0.9