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.
