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
