On 2014-02-06 06:42, Michele Bergonzoni wrote:
I am trying to emulate the obsoleted option
authenticate_ip_shortcircuit_ttl using the tecnique suggested by Amos
in:
http://www.squid-cache.org/mail-archive/squid-users/201201/0333.html
but with an important difference: I want to actually set the login
name in the request for subsequent processing (allow/deny and
tcp_outgoing_address selection). I am using squid version 3.2.5, and
tried with 3.4.3 as well.
I am using two external ACL helpers, one used in the very first
http_acces statement, and one just after the first auth-requiring
http_access line. I am using redis as a cache.
The first helper has format %SRC and, if found in cache, sets
"user=<username>"-
The second has format %SRC %LOGIN %EXT_LOGIN and captures valid
IP/username association, skipping the ones produced by the first
script.
The use of %LOGIN requires currently present and valid user credentials
just to test this ACL. This is only true inside the auth TTL period. At
the times when short-circuit has no meaning or usefulness.
That is why my original message uses %{Proxy-Authenticate}<h in the
format instead of %LOGIN.
Short-circuit leverages the fact that client software is never informed
of the Basic auth TTL and continues to send Proxy-Auth header with
credentials for Basic scheme on new connections and after the TTL has
expired. And the fact that a bare IP with _no credentials at all_ can be
*assumed* to be from a previously authenticated user.
The second script works and I can see the cache filling up.
The first script half-works. It works in the sense that the username
gets written in access.log. It doesn't work in the sense that
authentication is actually being asked to the user again, i.e. I have
lines in access.log with TCP_DENIED/407 and the valid (and correct)
username, and from the debug I know that it is the username that I set
into the first helper.
But you cannot. That is the problem with short-circuit. It has nothing
to do with the username itself, which is probably *already*
expired/invalid and may not even exist in that transaction.
==> If the username was present and still unexpired or valid
short-circuit would not be needed at all. Either the auth helper would
return OK, or the auth TTL value has not expired.
I am missing something? Maybe setting user= with an external ACL isn't
really a good thing? I tried with helpers returning "OK
username=<url-encoded-username>" as well as "ERR
username=<url-encoded-username>".
The key name is "user=" and you can test it later in the configuration
using the "ext_user" ACL type.
Other keys such as 'username=' are ignored in Squid older than 3.4. In
Squid-3.4 they are treated as annotations and you can test for values
later in the transaction with the "note" ACL type.
Ideas? Is anyone actually using username= in ACL helpers?
I also tried to wrap ntlm_auth, but in the auth_param protocol there
is no IP address to be used as cache key.
Nor any username. Nor any password. Nor any cache. Nor any TTL to
short-circuit.
The NTLM (and Negotiate) credentials are tied to the specific TCP
connection and persist for *as long as that connection does*. NTLM has a
mandatory unique per-connection encryption token. All you have to do is
enable persistent connections and keep-alive in the client, proxy, and
server software.
So, if the connection originally authenticated is still alive, then the
credentials are still attached and valid on it. No need for
short-circuit.
If you are using short-circuit to make different credentials re-use a
NTLM username then you need to be aware that the connection persistence
required by NTLM is not enforced, and more importantly the client and
server connections are not pinned/linked together. As a result HTTP
traffic multiplexing behaviour on the server connections will be
performed. ie traffic from all clients will be randomly jumbled up by
your proxy - with no traceability and NO authentication.
Amos
