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 <squ...@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.b...@googlemail.com> wrote in message >> news:4a3250ab1003290408q72ec495an7d04934d527c3...@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.b...@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 <squ...@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 >
