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@xxxxxxxxxxxxxx> wrote in message
news:4a3250ab1003290408q72ec495an7d04934d527c345d@xxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxx>:
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@xxxxxxxxxxxxx>:
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
