On Mon, Aug 23, 2010 at 11:09 AM, Bucci, David G <david.g.bucci@xxxxxxxx> wrote: > Hi, I’m still working on a Squid-based SSL VPN approach, involving running Squid on each accessing client and on a server in our farm, and using client certificates for 2-way SSL authentication for the tunnel between the client and server proxies. > > As part of that, we would like to restrict access to the server-side Squid, so that we’re guaranteed that all traffic came through a client-side proxy. For example, we would like to prevent users from setting their proxy to directly use the server proxy, bypassing localhost:3128. > > Is there any way to enable this level of control? The only way I could infer from rtfm was to rely on a client certificate as a shared secret – but we want the user’s client certificate to be used by the PC-side Squid instance, and so can't use a different certificate we would issue (can we?). Worst case, we can probably accept the user passing in the correct certificate as part of a legitimate SSL connection from software other than the PC Squid instance (e.g., from their browser). But for transaction logging purposes, we prefer they be forced to go through the client proxy. > > Note we’re deploying into other organizations, and this VPNing is only for a subset of URLs they access (ours) – so we don’t have complete control over the client configuration. That’d be way too easy ☺ … > > Thoughts? > > ---- > David G. Bucci > david.g.bucci@xxxxxxxx > > 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 > > > > There is no safe way I think. But If you want to do a light check you can look at Via headers. Squid adds that headers to show that he is in the middle. There is no acl to check that, you will need to write an external_acl_type. Regards, Diego -- Diego Woitasen XTECH
