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<[email protected]> 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. > > >
