Re: [squid-users] Squid sends TCP_DENIED/407 even on already authenticated users

2008-05-05 Thread Julio Cesar Gazquez
El Viernes 02 Mayo 2008 22:15:25 escribió:
 On ons, 2008-04-30 at 13:29 -0300, Julio Cesar Gazquez wrote:
  We are starting to deploy digest based authentication on a large network,
  and we found a weird problem: Sometimes authenticated requests are
  answered by TCP_DENIED/407 responses.

 Which Squid version?

Squid 2.6.18, and also observed on Squid 3 (-pre6). 

Yet at this point, once dismissed digest's nonce changes, the problem seems to 
be a corner case on the combination of a broken browser (IE7) and a broken 
website (rosario3.com) doing weird things. 

-- 
Julio César Gázquez
Area Seguridad Informática -- Int. 736
Municipalidad de Rosario


Re: [squid-users] Squid sends TCP_DENIED/407 even on already authenticated users

2008-05-02 Thread Julio Cesar Gazquez
El Jueves 01 Mayo 2008 06:08:28 escribió:

But, as far as I can tell, credentials are sent in the request as they appear 
in the log. Just happens that, after several successfull responses, 407 
responses happen.

Anyway, IE7 only ask again for authentication on a certain site, it keeps 
working silently on the other sites we tried, and IE6, FF and Konqueror never 
ask for authentication again, even if 

 1) Have you tried the auth TTL settings.

 2) are you certain that this is not simply a case of long-ago provided
 credentials timing out in IE?

No. While I found it seems having TCP_DENIED/407 is normal because squid 
changing nonces to limit reply attacks. However the IE7 problem asking again 
for credentials (found in a single site: rosario3.com, sadly one in the top 5 
in our stats) I guess could be a problem about IE7 and/or IIS broken 
implementation of digest RFC (RFC 2617). 



-- 
Julio César Gázquez
Area Seguridad Informática -- Int. 736
Municipalidad de Rosario


[squid-users] Squid sends TCP_DENIED/407 even on already authenticated users

2008-04-30 Thread Julio Cesar Gazquez
Hi.

We are starting to deploy digest based authentication on a large network, and 
we found a weird problem: Sometimes authenticated requests are answered by 
TCP_DENIED/407 responses.

Below is a sample from the access log:

1209559977.471252 192.168.2.223 TCP_MISS/200 801 GET 
http://www.deautos.com/img/top02.gif lboullo0 FIRST_UP_PARENT/localhost 
image/gif
1209559977.640 67 192.168.2.223 TCP_MISS/200 9208 GET 
http://www.deautos.com/img/tmp/img_comprar.jpg lboullo0 
FIRST_UP_PARENT/localhost image/jpeg
1209559977.647 50 192.168.2.223 TCP_MISS/200 9565 GET 
http://www.deautos.com/img/tmp/img_vender.jpg lboullo0 
FIRST_UP_PARENT/localhost image/jpeg
1209559977.656 77 192.168.2.223 TCP_MISS/200 5629 GET 
http://www.deautos.com/img/tmp/txt_comprar.jpg lboullo0 
FIRST_UP_PARENT/localhost image/jpeg
1209559977.657 63 192.168.2.223 TCP_MISS/200 655 GET 
http://www.deautos.com/img/img_flechita.gif lboullo0
FIRST_UP_PARENT/localhost image/gif
1209559978.080  2 192.168.2.223 TCP_DENIED/407 2765 GET 
http://www.deautos.com/img/img_flechita_blink.gif
lboullo0 NONE/- text/html
1209559978.163 87 192.168.2.223 TCP_MISS/200 2772 GET 
http://www.deautos.com/img/img_vender02.gif lboullo0
 FIRST_UP_PARENT/localhost image/gif
1209559978.219 97 192.168.2.223 TCP_MISS/200 707 GET 
http://www.deautos.com/img/img_flechita_blink.gif lboullo0 
FIRST_UP_PARENT/localhost image/gif

As you can see, the user is happily sending authenticated requests, yet at one 
point it receives a 407 response. 

We are not really sure, but this doesn't seem ok. Worst of all, in certain 
cases seems to be the cause of IE7 asking authentication again.

We tried everything we were able of: Raising the auth children limit, 
disabling Dansguardian, and googled around with no luck. Below is the auth 
configuration. 

=snip
auth_param digest program /usr/lib/squid/digest_ldap_auth 
  -b ou=People,ou=proxy,ou=Servers,o=MCR -u uid 
  -A l -D cn=nss,o=MCR -w x -e -v 3 -h ldap.pm.rosario.gov.ar

auth_param digest realm Clave Navegacion Internet
auth_param digest children 10
=snip

-- 
Julio César Gázquez
Area Seguridad Informática -- Int. 736
Municipalidad de Rosario