Oh, ok, thank you. Btw, I'm going to attempt to point to a generic location for the user's certificate (e.g. h:\cert.pem, where all user's home directories are mounted as H:) with a single cache_peer line, then have a "squid -k reconfigure" execed as part of their login. We're ok with only allowing a single user logged in at a time on the PC. I'll report back on how that goes. Thx. -----Original Message----- From: Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx] Sent: Wednesday, August 04, 2010 11:01 AM To: squid-users@xxxxxxxxxxxxxxx Subject: EXTERNAL: Re: Feasibility - Squid as user-specific SSL tunnel (poor-man's V Bucci, David G wrote: >> Multiple users with per-user certificates just get multiple cache_peer entries (one per user certificate) for Squid S. > > I'm sorry, can you explain that a bit more? Do you mean Squid S would need to have an entry ahead of time in squid.conf for each user, pointing to something different for each user certificate that Squid C might try to use to connect to it in 2-way SSL mode? > Sorry, I was not very clear. Squid S only needs the CA which Squid C certificates are signed by (eg Verisign). Squid *C* needs a cache_peer line for each separate certificate it uses to contact Squid S. > If all the user certificates were issued by a valid CA (e.g., Verisign), why would it not be enough for Squid S to have sslcafile|sslcapath point to CA certs that the user certificates chain to (e.g., a CA cert for Verisign)? > > Or am I completely missing the point? > > Thx! > > -----Original Message----- > From: Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx] > Sent: Wednesday, August 04, 2010 6:21 AM > To: squid-users@xxxxxxxxxxxxxxx > Subject: Re: RE: EXTERNAL: Re: [squid-users] Feasibility - Squid as user-specific SSL tunnel (poor-man's V > > >> -----Original Message----- >> From: Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx] >> Sent: Tuesday, August 03, 2010 7:39 AM >> To: squid-users@xxxxxxxxxxxxxxx >> Subject: EXTERNAL: Re: Feasibility - Squid as user-specific SSL tunnel (poor-man's V >> >> Bucci, David G wrote: >>> Hi, all - about to play with an approach to something, and I was >>> hoping to bounce the idea off people here - pls let me know if that's >>> not strictly within bounds/intents of the mailing list (new here). >>> This is close to the same concept as discussed here with a D.Veenker, >>> in an exchange in April/2010 -- but not quite the same. >>> >>> Is it possible to use Squid to create an ssh-tunnel effect, including >>> use of a client certificate? This would be to layer in SSL and client >>> authentication, for applications and web servers for which (for >>> reasons I won't go into here) it's not possible to reconfigure/recode >>> to use SSL. > <snip> >> One more comes to mind: client apps wanting Squid to perform the SSL wrapping need to send an absolute URL including protocol to Squid (ie https://example.com/some.file). They can do that over regular HTTP. >> Squid will handle the conversion to HTTPS once it gets such a URL. >> >> In the case where you have a small set of domains that are pre-known somehow there is an alternative setup which is much more in to a VPN than what you are currently thinking. >> >> Consider two squid setup as regular proxies: Squid C where the client apps connect and Squid S which does the final web server connection. >> >> Squid C gets configured with a parent cache_peer entry for Squid S with the SSL options. >> >> The domain names which require the HTTPS link are forced (via never_direct and cache_peer_access) to use the peer. Other requests are permitted to go direct and maybe denied access through the peer. >> >> That is it. >> >> Multiple users with per-user certificates just get multiple cache_peer entries (one per user certificate) for Squid S. >> > Bucci, David G wrote: > > Thank you for replying! Couple clarifications - the solution IS for > a known small set of domains, and all calls to those domains can have > the solution applied. > > > <snip> > > > > All of that said -- your solution that uses the server's Squid as a > cache-peer seems like it would work, and is very elegant. I'm confused, > though -- the server side proxy would be configured as a regular proxy, > not a reverse? I don't get that. Wouldn't it have to be a reverse, in > order to forward the call on to the real web server? These are web > service calls, they'll never actually be in cache. And if so, would > that solution still work, using the server proxy in reverse proxy mode > as a cache-peer? > > > > Reverse-proxy handling is only needed if the clients are unaware that > its a proxy. It depends on DNS configuration for the domain pointing at > the gateway proxy, and does extra request handling to map a web-server > formatted request into something it can handle better. > > > Since this setup we know that both ends of the SSL link are proxies we > don't need any of that special handling. It's just a basic heirarchy of > two proxies which happen to SSL their link. > > Amos -- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.6 Beta testers wanted for 3.2.0.1
