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. > > >Received on Fri Jul 03 2009 - 15:11:30 MDT
This archive was generated by hypermail 2.2.0 : Fri Jul 03 2009 - 12:00:03 MDT