RE: [PATCH] http(s): automatically try NTLM authentication first

From: David Turner <david.turner@twosigma.com>
Date: Feb 23, 2017, 01:03 UTC
Message-ID: <b152fad7e79046c5aa6cac9e21066c1c@exmbdft7.ad.twosigma.com>
In-Reply-To: <20170222233419.q3fxqmrscosumbjm@genre.crustytoothpaste.net>

Show 20 quoted lines

> -----Original Message-----
> From: brian m. carlson [mailto:sandals@crustytoothpaste.net]
> 
> This is SPNEGO.  It will work with NTLM as well as Kerberos.
> 
> 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.

NTLM on its own is bad:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa378749(v=vs.85).aspx says:

"
1. (Interactive authentication only) A user accesses a client computer and 
provides a domain name, user name, and password. The client computes a 
cryptographic hash of the password and discards the actual password.
2. The client sends the user name to the server (in plaintext).
3. The server generates a 16-byte random number, called a challenge or 
nonce, and sends it to the client.
4. The client encrypts this challenge with the hash of the user's password 
and returns the result to the server. This is called the response.
..."

Wait, what? If I'm a malicious server, I can get access to an offline oracle for whether I've correctly guessed the user's password? That doesn't sound secure at all! Skimming the SPNEGO RFCs, there appears to be no mitigation for this.

So, I guess, this patch might be considered a security risk. But on the other hand, even *without* this patch, and without http.allowempty at all, I think a config which simply uses a https:// url without the magic :@ would try SPNEGO. As I understand it, the http.allowempty config just makes the traditional :@ urls work.

Actually, though, I am not sure this is as bad as it seems, because gssapi might protect us. When I locally tried a fake server, git (libcurl) refused to send my Kerberos credentials because "Server not found in Kerberos database". I don't have a machine set up with NTLM authentication (because, apparently, that would be insane), so I don't know how to confirm that gssapi would operate off of a whitelist for NTLM as well.