[squid-users] One Time Password with squid, exists?

Amos Jeffries squid3 at treenet.co.nz
Thu Mar 12 03:02:31 UTC 2015


On 12/03/2015 3:25 p.m., Eliezer Croitoru wrote:
> Thanks Amos,
> 
> So NTLM has "two steps" authentication which means that there is a basic
> negotiation over the http connection to the proxy which makes it less
> secure then kerberos.
> 
> (speculating)
> The main reason it's less secure then kerberos is that every part of the
> password negotiation steps is being done in the same channel that the
> proxy is being contacted and there for cannot apply a third party
> "verification" for the authenticity of any of the tokens.
> As a matter of fact NTLM http proxy authentication may be intercepted
> and can do lots of bad things to the connections.

No, quite. The main reason is that NTLM (without NTLMv2 extensions)
contains silent downgrade to several LM protocol versions that either
send the password in username:password form or only encode it with a
8-bit hash that can be decoded as easily as base64 Basic auth. NTLMv1
does that whenever the client/attacker wants it to. NTLMv2 is better,
but still has relatively easily decrypted keys and the interception
problem you are aware of.

The Squid SMB_LM helpers work by using that LM weakness. Which is why
they dont work with Windows systems newer than 2006 when MS started
removing NTLMv1 support at the code level.

> 
> I will try to read more about Digest authentication to make sure I will
> not create something when it's not needed.
> 
> But in any case that there is an option to make the proxy to client
> connection one level more secure then plain http proxy port it should be
> considered better, right?

Perhapse. It depends on whether that step-up is actually better. There
are a lot of attempts and possible ways to do it that leave people worse
off than where they started (ie the LM issues).

The most secure authentication I've seen so far was simply Basic auth
with a per-message client PKI key exchange in the username:password
fields and server response encrypted using the provided key. Thats a bit
over the top for most uses though, it require a lot of CPU time at both
ends and ability to create many keys fast.


PS. I also have that experimental branch containing OAuth 2.0 Bearer
implementation for Squid which can simplify things at least for Squids part.

Amos



More information about the squid-users mailing list