Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
POP3 NTLM authentication got broken in between 7.37 and 7.38 #718
I did this
I wanted to connect to our exchange server using POP3. I got a login denied (67) message.
I expected the following
I expected to list/retrieve test emails.
Anything above 7.37 does not work. I tried "official" Win builds from the website. First 7.46 then the current latest 7.47.1. Then I tried it on my Linux box (7.35) and that worked. I had an older build (7.40) (built by myself) that did not work either. I started building all the version between 7.35 and 7.40 and found that 7.38 does not but 7.37 does work. I built the versions in the same way with the same dependencies the only thing that was different from build to build is the curl source code.
If I change the code in 7.38 in pop3.c:
[curl -V output perhaps?]
Ubuntu 14.04.4 and Windows7
My apologies if I am missing something but I don't see what is wrong.
In v7.38 we introduced support for GSSAPI (Kerberos V5) authentication and as the Exchange Server is advertising: NTLM, GSSAPI and PLAIN we are choosing the most secure mechanism as follows:
curl >= 7.38 - GSSAPI
We can clearly see this in the logs as follows:
I suspect the Kerberos authentication is failing as it is unable to obtain the Security Credentials for the User - Kerberos is a little more picky than NTLM as a Kerberos 5 ticket needs to be obtained before actually sending anything over the wire.
As such I suspect that the call to AcquireCredentialsHandle() in curl_sasl_sspi.c:940 is failing.
If you want to specifically use NTLM you can use the following to request NTLM as opposed to GSSPI:
Cool - i'm glad NTLM's working for you. You can use GSSAPI with an Exchange Server using curl - in fact it's how I developed the SASL GSSAPI support in curl ;-)
It's just a little more fiddle:
a) You need to include the domain name in the user name (either using down-level format or as an UPN).
This is definitely a backwards compatibility issue!
All users that relied on NTLM authentication (which was working) are now forced to update their configuration, as the newly implemented GSSAPI seems to require a domain name. cURL does not fall back to NTLM if GSSAPI fails. Neither do we have a chance to just disable GSSAPI from the API level. We can just force NTLM, which does not work for all cases.
As cURL strives for backwards compatibility, i hope that you can reconsider reopening the issue.
I'm inclined to agree with you. As GSSAPI was previously ignored curl picked NTLM just fine so by adding support for that we broke how curl used to work against the same server. I'm not sure exactly what the spec says, but I would guess that we could try another if the first method fails. Alternatively, we could alter the priority order of the auth methods or something.
This said, just opening this bug will not magically result in this problem getting fixed. Someone also needs to actually step up and work on the code. I'm opening this now, but I will close it again if it goes stale and then instead add the bug to the
Thanks for reopening. You can also add SMTP and IMAP labels, as those are affected as well.
Hints to the ideas on how to fix the problem:
In my opinion GSSAPI differs from other auth method, while with other methods if auth failed via NTLM (on supporting server) it'll probably fail with Basic with the same password, but GSSAPI fails if it doesn't have a ticket, without actually trying.
So we could just remove gssapi from supported auth method of this request if it fails to generate a token (I don't think it is a security concern as the user denotes what auth methods to support).
I'm not familiar with POP code but I can picture how it would look in HTTP Negotiate code where we have the same problem basically, see issue #876 for instance.
referenced this issue
Aug 21, 2016
This fixes the issue for the most part except possibly when a GSS-API based library is used and the user in the credientials cache still fails to generate a token.
As such we could modify the new Curl_auth_user_contains_domain() function futher to attempt to generate a token when using GSS-API.
But at least it is a step in the right direction ;-)