Re: [squid-users] Feasibility - Squid as user-specific SSL tunnel (poor-man's VPN)

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_at_treenet.co.nz]
> Sent: Wednesday, August 04, 2010 6:21 AM
> To: squid-users_at_squid-cache.org
> Subject: Re: [squid-users] RE: EXTERNAL: Re: [squid-users] Feasibility - Squid as user-specific SSL tunnel (poor-man's V
>
>
>> -----Original Message-----
>> From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
>> Sent: Tuesday, August 03, 2010 7:39 AM
>> To: squid-users_at_squid-cache.org
>> Subject: EXTERNAL: Re: [squid-users] 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