Re: [squid-users] Re: Negotiate/NTLM authentication caching

Markus and Amos, thx for your replies! But are you sure there is no
caching for "auth_param" helpers? Because I could swear that the H(A1)
at the digest hashing is only computed once. At least I think I
remember it this way. Hmm, I guess I have to look at that again more
closely.

Regards,
Khaled

2010/3/30 Amos Jeffries <squid3_at_treenet.co.nz>:
> Markus Moeller wrote:
>>
>> I  may misunderstood what you said, but there is no caching of
>> authentication for Kerberos nor Basic/Digest. I think the TTL you talk about
>> is for authorisation.
>>
>> Markus
>>
>
> Quite right.
>
> Amos
>
>
>> "Khaled Blah" <khaled.blah_at_googlemail.com> wrote in message
>> news:4a3250ab1003290408q72ec495an7d04934d527c345d_at_mail.gmail.com...
>> Thx a lot for your answer, Amos! You are of course right with your
>> concerns towards "IP/TCP caching". Not a very good idea!
>>
>> Does the same hold true for Kerberos as well, though? I mean could it
>> be possible to cache Kerberos authentication in a secure fashion?
>>
>> Thinking about what you said, I am wondering what the big difference
>> is to Basic/Digest authentication. I mean with them squid challenges
>> the user as well, the credentials the user's client sends are being
>> verified by the authentication helper and that result is cached so
>> that when the same user requests anything with the same credentials,
>> he or she will not be re-verified with the helper's help until the TTL
>> has passed, right? So what am I missing here?
>>
>> Thx in advance for any insight you can give me on this!
>>
>> Khaled
>>
>> 2010/3/28 Khaled Blah <khaled.blah_at_googlemail.com>:
>>>
>>> Thx a lot for your answer, Amos! You are of course right with your
>>> concerns towards "IP/TCP caching". Not a very good idea!
>>>
>>> Does the same hold true for Kerberos as well, though? I mean could it
>>> be possible to cache Kerberos authentication in a secure fashion?
>>>
>>> Thinking about what you said, I am wondering what the big difference
>>> is to Basic/Digest authentication. I mean with them squid challenges
>>> the user as well, the credentials the user's client sends are being
>>> verified by the authentication helper and that result is cached so
>>> that when the same user requests anything with the same credentials,
>>> he or she will not be re-verified with the helper's help until the TTL
>>> has passed, right? So what am I missing here?
>>>
>>> Thx in advance for any insight you can give me on this!
>>>
>>> Khaled
>>>
>>> 2010/3/28 Amos Jeffries <squid3_at_treenet.co.nz>:
>>>>
>>>> Khaled Blah wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I'm developing an authentication helper (Negotiate/NTLM) for squid and
>>>>> I am trying to understand more how squid handles this process
>>>>> internally. Most of all I'd like to know how and how long squid caches
>>>>> authentication results. I have looked at the debug logs and they show
>>>>> that squid seems to do "less caching" for Negotiate/NTLM than it does
>>>>> for Basic/Digest authentication. I am wondering whether I can do
>>>>> something about this so that a once verified user will only get his
>>>>> credentials re-verified after a certain time and not all during. I am
>>>>> grateful to any insight the list can give me. Thanks in advance!
>>>>>
>>>>> Khaled
>>>>
>>>> NTLM does not authenticate a user per-se. It authenticates a TCP link to
>>>> a
>>>> some form of account (user being only one type). Squid holds the
>>>> authentication credentials for as long as the authenticated TCP link is
>>>> open. It challenges the browser on any requests without supplied
>>>> credentials, and re-verifies on every new link opened or change in
>>>> existing
>>>> credentials.
>>>>
>>>> Caching NTLM credentials for re-use on TCP links from specific IP
>>>> addresses
>>>> has always been a very risky business. As the world is now moving
>>>> further
>>>> towards NAT and proxy gateways a single IP address can have multiple
>>>> requests from multiple clients. This makes caching NTLM credentials an
>>>> even
>>>> worse prospect in future than it is now or ever before.
>>>>
>>>> What we are doing in Squid-3 now is improving the HTTP/1.1 support which
>>>> enables TCP links to be held open under more conditions than HTTP/1.0
>>>> allows
>>>> and thus the length of time between credential checks to be lengthened
>>>> without loosing security.
>>>>
>>>> I can tell you now that any patches to do with caching credentials will
>>>> be
>>>> given some very strict checks even to be considered for acceptance into
>>>> Squid.
>>>>
>>>> Amos
>>>> --
>>>> Please be using
>>>> Current Stable Squid 2.7.STABLE8 or 3.0.STABLE25
>>>> Current Beta Squid 3.1.0.18
>>>>
>>>
>>
>>
>
>
> --
> Please be using
>  Current Stable Squid 2.7.STABLE9 or 3.1.1
>
Received on Tue Mar 30 2010 - 09:56:58 MDT