-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/11/2014 5:26 p.m., Victor Sudakov wrote: > Amos Jeffries wrote: >>> >>> If we speak about Kerberos authentication. On the very first >>> request, the browser receives a "407 Proxy Authentication >>> Required" reply and learns that it is expected to provide >>> credentials. For a certain amount of time, the browser knows >>> that it should send the credentials with every request without >>> waiting for an 407 reply. >>> >>> How long is this amount of time? Is it like forever? Is there >>> ever a limit after which the browser will try again to send a >>> request without credentials? Maybe after a browser restart or >>> what? >>> > >> Negotiate/Kerberos (and NTLM) do not authenticate the request. >> They abuse HTTP to authenticate the TCP connection underneath >> HTTP. So the credentials must be re-used for the entire lifetime >> of that TCP connection. Changing credentials means tearing down >> that whole TCP connection. > > As far as I understood you, there would be a "407 Proxy > Authentication Required" and "Proxy-Authorization: Negotiate" pair > in each TCP connection between browser and proxy. 407 is repeated as many times as necesary until the client starts sending valid credentials. Proxy-Authorization is used on every request containing any credentials. That is the basic requirement for any HTTP auth schemes. They are not a pair. Since there is no requirement for anything to follow the 407. Nor is there even a requirement for the two messages to be sent on the same TCP connection (eg "auth_param ... keep_alive off"). Statelessness is fun sometimes. > > If the connection is used for several requests, only the first > HTTP request in the connection would contain authentication info. No. Once authentication is accepted on a connection the credentials token MUST be sent on all following requests. - So far that is basic HTTP auth requirements. Now things get weird... Lack of Negotiate credentials on any request is a sign of injection attack being performed and the TCP connection must be torn down. To do that tear-down Squid can send 407 challenge with Connection:close such that the client can resume with re-authentication on new TCP connection(s) without waiting for any 407. > But each new TCP connection is re-authenticated by HTTP. Is this > correct? Not really. A TCP connection may be used for multiple requests before one needs to authenticate and kicks out a 407. If you offer Basic Digest, Bearer or other properly HTTP compliant auth schemes there is even the possibility that multiple different types of credentials were happily being multiplexed over the single connection until NTLM/Negotiate gets in the way. Amos -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUaZrRAAoJELJo5wb/XPRjCNIH/2/Shwg113XcpKnyF+CATG8C vxpa88xuajuqiwHRBtPd6caQDbnQi05HXuoD+RUmS+bhLeHhFg/5AZPswnCLLp7N SmoOcc7yB80+0/Cmy31CpfO0QWm5GnkMHM40Kj7Lftms2AUKdOtmxoBITJYKTmPf hXEktNtD78K8rB0qHg5s38Z/wd3K7YNvGTBlNacbpLM0TYx1CELkccA7ifx+t3Ut rLKqZJHUbSWAhmBeHs6eLu2KXp+0ZA1gp5HqDmg7XaRtzWAJpy9K0+zpPEVdVZcz rYPsCjdOuesHrWc99pNp4d3RFggXQ6298eJHthhNwqdVwMhhkfRGcp1fyNNIx2E= =8j6B -----END PGP SIGNATURE----- _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users