Re: [squid-users] Writing username= from external_acl helper

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
Received on Thu Feb 06 2014 - 06:30:43 MST