On Mon, 23 Aug 2010 13:18:18 -0300, Diego Woitasen <diegows@xxxxxxxxxxxx> wrote: > 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 Thats pretty much it. Via: or QoS TOS/Diffserv values passed in the packets from the client-end Squid. Maybe a combo of the two. TOS may encounter problems if any of the transit networks strip the QoS. It may change in future, but for now browsers do not support TLS/SSL/HTTPS to proxies. If your server end proxy is rejecting non-HTTPS connections clients bypassing the localhost:3128 and still getting a usable link will be a rarity. Amos
