Jeff King <p...@peff.net> writes: > On Wed, Feb 22, 2017 at 11:34:19PM +0000, brian m. carlson wrote: > >> Browsers usually disable this feature by default, as it basically will >> attempt to authenticate to any site that sends a 401. For Kerberos >> against a malicious site, the user will either not have a valid ticket >> for that domain, or the user's Kerberos server will refuse to provide a >> ticket to pass to the server, so there's no security risk involved. >> >> I'm unclear how SPNEGO works with NTLM, so I can't speak for the >> security of it. From what I understand of NTLM and from RFC 4559, it >> consists of a shared secret. I'm unsure what security measures are in >> place to not send that to an untrusted server. >> >> As far as Kerberos, this is a desirable feature to have enabled, with >> little downside. I just don't know about the security of the NTLM part, >> and I don't think we should take this patch unless we're sure we know >> the consequences of it. > > Hmm. That would be a problem with my proposed patch 2 then, too, if only > because it turns the feature on by default in more places. > > If it _is_ dangerous to turn on all the time, I'd think we should > consider warning people in the http.emptyauth documentation.
I presume that we have finished discussing the security ramification, and if I am not mistaken the conclusion was that it could leak information if we turned on emptyAuth unconditionally when talking to a wrong server, and that the documentation needs an update to recommend those who use emptyAuth because they want to talk to Negotiate servers to use the http.<site>.emptyAuth form, limited to such servers, not a more generic http.emptyAuth, to avoid information leakage? If that is the case, let's take your 1/2 in the near-by thread without 2/2 (auto-enable emptyAuth) for now, as Dscho seems to have a case that may be helped by it.
