-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ntlm: support version 2 on 32-bit platforms and fix negotiated flags usage #6849
Conversation
5dc6fda
to
ea6fd4f
Compare
lib/vauth/ntlm.c
Outdated
unsigned char ntbuffer[0x18]; | ||
unsigned char tmp[0x18]; | ||
unsigned char md5sum[CURL_MD5_DIGEST_LENGTH]; | ||
unsigned char md5sum[MD5_DIGEST_LENGTH]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this change? We provide our own define to make sure it exists under a single name. There's no guarantee there's a MD5_DIGEST_LENGTH
define provided in systems! See d80d419 that introduced our name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right, thanks for pointing it.
I intended to replace by MD5_DIGEST_LEN
which is defined in curl_md5.h
. Will fix it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed by using MD5_DIGEST_LEN
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you remove the CURL_MD5_DIGEST_LENGTH
define as well then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, because it was local to vauth/ntlm.c.
We need to figure out how to get someone to run such tests! I don't have any such servers/services to test against and I don't know who does! 🤔 |
We're both linux guys, that's why we are in the same situation. I would prefer not to have it committed for "testing by the community". |
I wrote the initial NTLM implementation in curl...
... I believe you, but still it has been right enough to work pretty well for a lot of users over the years. |
Congratulations! I guess it was not that easy when no official documentation was released. |
Other users at the time tested it against actual NTLM-using servers before I wrote up the test cases that verifiy that we maintain the same behavior. |
I had to adapt the tests as the NTLM response in type 3 message changes. I did it manually, checking that only the targeted message part was affected. I guess NTLM is not much used nowadays. |
According to our user survey 2020, 9.9% of our users use it, down just a little from 10.3% the year before. I think that's a pretty sizable share after all. |
Maybe we should call them for evaluation, via the mailing list for example ? |
FWIW, I'm one of those who use NTLM (via SSPI though), but NTLMv2 only would suffice for me. I can try to find a test server and test this patch. |
Many thanks Marcel, |
... as !defined(CURL_DISABLE_CRYPTO_AUTH) is a prerequisite for the whole NTLM.
According to Microsoft document MS-NLMP, current flags usage is not accurate: flag NTLMFLAG_NEGOTIATE_NTLM2_KEY controls the use of extended security in an NTLM authentication message and NTLM version 2 cannot be negotiated within the protocol. The solution implemented here is: if the extended security flag is set, prefer using NTLM version 2 (as a server featuring extended security should also support version 2). If version 2 has been disabled at compile time, use extended security. Tests involving NTLM are adjusted to this new behavior. Fixes curl#6813
OK, I performed additional test with IIS7 and it works. Here is a table of what is used depending on curl and server capabilities:
Entries marked with ! are wrong and will fail, but these situations will probably never occur. It should be ready now. |
The |
No because as V2 cannot be negotiated, curl does not see server supports V2. We thus assume that V2 is supported only if V1ext is. IMHO this is the safest way. |
OK, makes sense. I thought that V1ext + V2 looked the same to the client instead of V1 + V2. |
No. In fact a V2-aware server does not care about the extended security flag when determining V2 is used: it only checks the NTLM response length. The only other solution to the problem is to never use V2 (this will also remove a lot of code), but I don't think you will feel satisfied with it :-) |
Thanks for your review and work on this, Marcel. |
Thanks! |
According to Microsoft document MS-NLMP, current flags usage is not accurate: flag NTLMFLAG_NEGOTIATE_NTLM2_KEY controls the use of extended security in an NTLM authentication message and NTLM version 2 cannot be negotiated within the protocol. The solution implemented here is: if the extended security flag is set, prefer using NTLM version 2 (as a server featuring extended security should also support version 2). If version 2 has been disabled at compile time, use extended security. Tests involving NTLM are adjusted to this new behavior. Fixes #6813 Closes #6849
Thanks for pulling. |
This does not affect sspi builds.
I successfully performed as many tests as my non-M$ environment allows to, but this must be tested against a genuine M$ server, although I'm quite confident in it.
Thanks for considering it.