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_at_squid-cache.org
> 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_at_lmco.com (unclass)
> david.bucci_at_gdit.com (AIT unclass) gsdgb01_at_geoscout.ndn.nga.ic.gov (JWICS)
> 877.547.9681 or dabooch_at_skytel.com 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
Received on Fri Aug 27 2010 - 07:22:31 MDT
This archive was generated by hypermail 2.2.0 : Fri Aug 27 2010 - 12:00:03 MDT