> Idea is good, but most of webbrowsers don't support https to talk to > proxies. Syou may do a local ssh tunnel if you haave privileges. Thanks, Luis -- what I ended up with (topmost msg below) is an stunnel (similar to ssh tunnel), and the browser talk to the unencrypted endpoint on the PC (and the other endpoint decrypts and talks, also unencrypted, to the Squid proxy on the server:3128). So basically what you describe, but using stunnel instead of ssh to construct the tunnel. -----Original Message----- From: Luis Daniel Lucio Quiroz [mailto:luis.daniel.lucio@xxxxxxxxx] Sent: Friday, August 27, 2010 3:22 AM To: squid-users@xxxxxxxxxxxxxxx Subject: EXTERNAL: Re: Using Squid with stunnel (encrypting all traffic from PC to pr Le jeudi 26 août 2010 17:25:03, Bucci, David G a écrit : > Ok - I have a configuration that's working, and which I have to mull > on for a bit. I think I'm happy. I'm almost sure I'm not unhappy. Almost. > > Again, our problem is that we have 3rd party software (executable > client on > PC) that we can't SSL enable and that reaches out with HTTP to access > web services -- yet we have a customer req't to encrypt all traffic > used for those calls. We also can't change the URLs that the client > uses to reach the web services -- something about the HTTP headers needing to be right. > So a direct ssh or stunnel tunnel wouldn't work -- unacceptable to > change the service URLs the client knows about to > http://localhost/service. All we can do is set a proxy for the client. > > I had been trying to use Squid on both the PC and server, have the PC > squid "cache_peer ssl" to the server squid doing https_port ... but > this is all on Windows, and the Windows Squid packages were throwing openssl errors. > > I tried layering in stunnel under the Squid instances -- have the PC > squid cache-peer to an stunnel localhost:8081 pipe to stunnel > server:443, then have stunnel connect from there to Squid server:3128. > But that didn't work. The connection would get established, but the > stunnel instance on the server always timed out trying to talk to the > Squid instance on the server. Not sure why ... maybe something about > the socket usage dynamics, something optimized for the cache-peer TCP socket in squid? > > So now I've eliminated the Squid on the PC, and am having the client > software package (the one we can't SSL enable, and can't change target > URLs for) proxy directly to the localhost:8081 stunnel endpoint. That > successfully passes the proxy requests through an SSL tunnel to the > server stunnel, which passes them to Squid, which does a direct > retrieval, and passes content back through the chain. > > The net (no pun) effect is that client software doesn't need changed > URLs ... it just needs to proxy to the stunnel endpoint. That meets > our minimal requirements. We would have liked to use 2-way SSL > (reference the scheme Amos described, where we could have a cache-peer > entry/user, pointing at a user-specific cert). But we can live with > forcing basic authentication, even though the users will dislike > having to re-enter uid/pw. > > In any case, with the approach above, we don't have to install Squid > on the customer PCs, only stunnel alone -- so better in that sense. > And probably better performance, since the above has 1 less connection > leg (though it was local anyway, PC Squid to PC stunnel). > > Hmm ... what strange journeys we take, trying to meet customer req'ts. > > -----Original Message----- > From: Bucci, David G > Sent: Thursday, August 26, 2010 2:17 PM > To: squid-users@xxxxxxxxxxxxxxx > Subject: "Stable" (non-experimental) SSL support in Windows version? > Or anyone use Squid with stunnel? > > Hi - I'm starting to experience issues with SSL support in the Squid > version I d/l'ed from Acme Consulting. I picked the 2.7 STABLE8 > version, as being the closest to what I see recommended as the tagline in Amos' > emails. > > The error that I'm experiencing is an abort on the server side, with a > Windows event entry listing error message > "OPENSSL_Uplink(100EB010,07): no OPENSSL_Applink". Googling that, all > I find is the maintainer of the Acme Windows Squid package pointing > out that that's why SSL is labeled "experimental". > > I checked, and ALL of the versions from Acme have this disclaimer. > (not casting blame) > > So . does anyone know of a Windows version of Squid that's in wide > use, using SSL, and known to be stable? For our purposes, it would > need to run on Windows Server 2008. > > Or alternatively . has anyone used Squid with something like stunnel > on both cache machines between Squid instances in a cache hierarchy, > to encrypt the connection? And, ideally, have you used it in this > fashion with both of the Squid/stunnel instances running on Windows? > I'm concerned that the HTTP semantics change would break something - > that setting the cache_peer on the PC squid to 127.0.0.1:stunnel_port > would somehow mess up the parent peer being accessed, when it parses > the request sent to it by its own local stunnel instance. > > This all relates to the discussion here over the last month on > "wrapping" a piece of software whose client and server portions run > only on Windows, but which we can't add SSL support to . we need to > impose encryption on the connection. We could just use stunnel > directly, but then the HTTP headers would be affected, and we're > concerned there's app functionality that would be affected on the > server side. So we don't want to change the URL endpoints being > accessed all to localhost:stunnel_port, we need the HTTP header semantic "cleanliness" of proxy-based interception. > > ---- > David G. Bucci > Lockheed Martin IS&GS, Gaithersburg MD > 240.668.4024 (unclass) 851.4384 (class) david.g.bucci@xxxxxxxx > (unclass) david.bucci@xxxxxxxx (AIT unclass) > gsdgb01@xxxxxxxxxxxxxxxxxxxxxxx (JWICS) > 877.547.9681 or dabooch@xxxxxxxxxx Pager Telecon Dial-in: > 800.729.0918 PIN 541458# (610.354.1200 if in Lockheed Martin building) > > When Dr. Bruce Banner becomes angry, he changes into the Incredible > Hulk; when the Incredible Hulk becomes angry, he changes into Chuck > Norris. -- ChuckNorrisFacts.com Idea is good, but most of webbrowsers dont support https to talk to proxies. Syou may do a local ssh tunnel if you haave privileges. LD
