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
