Re: [squid-users] Problem with authentication data

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Fri, 13 Dec 2013 09:32:24 +1300

On 2013-12-13 04:23, Juergen Obermeyer wrote:
> Hello everybody,
>
> I'm rewriting to this list because my problems with the user
> authentication persist: all my users have to authenticate either with a
> Kerberos Ticket or with username/password. This authentication fails
> sometimes - please see the following two examples:
>
> (1) Client 1, Windows 7 with Firefox, basic authentication
>
> 1386845741.085 438915 <client_1> TCP_MISS/200 23228 CONNECT
> outlook.office365.com:443 <user_1> DIRECT/132.245.210.6 -
>
> 1386845741.142 54 <client_1> TCP_DENIED/407 1657 CONNECT
> outlook.office365.com:443 - NONE/- text/html
>
> After the first (successful) authentication, some milliseconds later
> the
> failure (same user!). Apparently, no authentication data is provided.

Yes. Consider this:
  * two packets leave your gateway router. Which comes from client_1 and
which comes from some attacker spoofing client_1 IP ?

There is no way to tell the difference if the request does not contain
credentials.

It is also highly unsafe for your clients software to send their
credentials until they are sure they have reached the server they were
trying to connect to. Information about the server and its
authentication credentials is provided by 407 messages in HTTP.

So what you are seeing is normal.

>
> (2) Client 2, Ubuntu 12.04 with Firefox, Kerberos
>
> 1386845730.212 50 <client_2> TCP_MISS/302 896 GET
> http://www.google.com/search? <user@REALM> DIRECT/173.194.32.212
> text/html
>
> 1386845743.861 145 <client_2> TCP_DENIED/407 1738 GET
> http://bits.wikimedia.org/de.wikipedia.org/load.php? - NONE/- text/html
>
> 1386845743.948 231 <client_2> TCP_MISS/200 33809 GET
> http://bits.wikimedia.org/de.wikipedia.org/load.php? <user@REALM>
> DIRECT/91.198.174.233 text/css
>
> Here we have a chain of success/failure/success (same user).

No. You have a chain of "success / new connection + needs credentials /
success ". 403 status is used for authentication _failure_.

>
> If you decode the time stamps, you will see that there differences are
> only about some milliseconds.
>
> Is anybody out there with an idea?

Yes. This is normal HTTP traffic.

Check whether you have client persistent connections enabled. When that
is working the client traffic will all be sent over connections it
already knows need authentication, so you should see far less 407 from
the proxy.

Amos
Received on Thu Dec 12 2013 - 20:32:26 MST

This archive was generated by hypermail 2.2.0 : Fri Dec 13 2013 - 12:00:04 MST