Search squid archive

Re: RE: EXTERNAL: Re: [squid-users] Feasibility - Squid as user-specific SSL tunnel (poor-man's V

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




-----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


[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux