On 01/23/2014 02:20 PM, Amos Jeffries wrote:
> On 2014-01-24 09:31, David Deller wrote:
>> Well, let me back up a little. If there was another way to
>> authenticate securely to Squid, that would also be acceptable.
> Those are the ones currently supported by Squid.
>
> Negotiate is only sort-of MS specific. It is usually a MS wrapper
> protocol around the Kerberos scheme. This is currently the most secure
> of auth schemes supported explicitly by Squid.
>
> NTLM is second best. NTLMv2 has most of the same high-security
> properties as Kerberos (slightly less algorithms though) but is much
> more MS-specific and violates HTTP protocol in nasty ways that block
> usage over the Internet / WAN.
>
> Digest is next best. The MD5 step is simply to one-way hash a short
> lived nonce, the password itself is never sent and the system can be
> configured to rotate nonces fast enough that replay attacks are very
> difficult (but not impossible).
>
> Basic auth is ironically both the worst and the best of all of them. It
> is just a scheme for sending two credential tokens to the service.
> Historically is has been used to send user:password details and that is
> terribly bad. However, provided you can configure both the sender and
> receiver to agree on algorithms out-of-band (the HTTP scheme provides no
> way to do so) you can send any type of secured one-use token in the
> "password" field. You just need the client to be able to generate them
> and a Squid Basic auth helper to verify and accept/reject. Properly done
> this can be far more secure than even Negotiate.
Just for completeness sake, there is also authentication based on client
SSL certificates. That is obviously a non-HTTP form of authentication
and it requires an SSL connection terminating at Squid, so it cannot be
used with popular browsers "as is".
HTH,
Alex.
Received on Fri Jan 24 2014 - 22:23:59 MST
This archive was generated by hypermail 2.2.0 : Sat Jan 25 2014 - 12:00:06 MST