> Squid *C* needs a cache_peer line for each separate certificate it > uses to contact Squid S. Getting back to this, Amos. Have roughed out the solution, but am now trying to layer in client certificates. Again, we have multiple users/PC, but can guarantee that only one user will be on at a time (no concurrent logon and remote access sessions, e.g.). I guess I'm not understanding how to make sure that the tunnel established between the squid instances (Client and Server) is authenticated with the user-specific certificate. I had thought I would have to brute-force it -- e.g., have a known location for a user certificate, a cache-peer line that points at that known location, and on user login have that particular user's certificate copied to that known location, then restart Squid C. But your mention of a cache-peer line per certificate implies there's a more elegant approach? Can you explain the above -- if I put a cache-peer line, pointing to a user-specific certificate for each user on the PC, how does Squid know which one to use? Does it somehow do it dynamically, based on the owning user of the process issuing the incoming request? If I do have to brute-force it, do you know if the Windows version accepts env vars in squid.conf, e.g. %HOMEPATH%? (may be a q. for Acme) The concept being, rather than having a known location, writeable by all users, I could have a single cache-peer line that points to %HOMEPATH%/usercert.pem, run Squid on the PC not as a service, and have it started up as part of a user's logon (so the env var is picked up). Thoughts? Thank you, as always. -----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
