Ok, Amos, now I finally understand in detail what you suggested below ...
and cool as it is, it won't work for us.
To review, what you outlined is an approach to having client software on
the PC authenticate to the local squid (forcing the authentication with an
"http_access allow !all"). Then, using the established identity, an SSL
connection using that user's certificate is selected/created via a
cache_peer line unique to that user.
And that's the problem - the whole point of this exercise is that this 3rd
party software we've been handed doesn't _support_ any authentication
mechanisms ... not coded for Kerberos/NTLM, won't handle SSL client certs,
not even basic auth. We're trying to impose the channel security from the
outside.
So, open to other ideas, but I'm back to having to securely copy the
user's SSL cert to a known location on login, and force a squid -k
reconfigure, so their cert is in use -- as basically an indirect way of
extending the domain authentication that occurred at login.
But all that said ... it's an innovative idea, what you outlined!
-----Original Message-----
From: Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx]
Sent: Tuesday, August 17, 2010 8:44 PM
To: Bucci, David G
Cc: squid-users@xxxxxxxxxxxxxxx
Subject: Re: RE: EXTERNAL: Re: [squid-users] Feasibility -
Squid as user-specific SSL tunnel (poor-man's V
On Tue, 17 Aug 2010 11:43:38 -0400, "Bucci, David G"
<david.g.bucci@xxxxxxxx> wrote:
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?
Well, yes. Still a bit of a blunt object though.
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?
The idea goes like this:
cache_peer can be configured with a client certificate (one AFAIK).
cache_peer can be selected based on arbitrary ACL rules
(cache_peer_access).
username can be found and matched with an ACL.
So... every user can have their own unique cache_peer entry in squid.conf
which sends their certificate out. :)
For easy management if you have more than a few users, I'd throw in the
"include" directive and have a folder of config snippets. One file per
user with their whole snippet included. Since its user specific and all
are identical the sequence of snippets is not to important between
themselves.
The problems remaining is that username has to be checked and cached in
the main access controls (http_access) so that it becomes usable to
cache_peer_access.
What we end up with is:
/etc/squid/users/snippet-JoeBlogs:
# match only this user
acl userJoeBlogs proxy_auth JoeBlogs
# forces the username to be looked up early. But !all prevents the allow
happening.
# if you have more general access controls that use a "proxy auth
REQUIRED" this can be skipped.
http_access allow userJoeBlogs !all
# private link to the master server for this user
cache_peer srv.example.com parent 443 0 name=peer-JoeBlogs ssl ...
cache_peer_access peer-JoeBlogs allow userJoeBlogs
cache_peer_access peer-JoeBlogs deny all
/etc/squid/squid.conf:
...
auth_param ....
...
include /etc/squid/users/*
http_access deny all
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
No. There is some limited support in specialized areas using the registry.
But not for files like that AFAIK.
Amos
