-
-
Notifications
You must be signed in to change notification settings - Fork 6.7k
Curl never completes SPNEGO security context over HTTP #5235
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
Comments
I'm not sure if that's expected behavior or not. @captain-caveman2k |
If that is expected behavior, then GSS-API based auth is pointless with curl. |
To be clear I mean that it's returning 200 succeeded and an authenticate header. Which does not make it pointless it just doesn't work for that case. |
Taking the status code into account doesn't make it secure. The status comes from application code while the response token from server code. The response token can basically appear in any status code |
200 means OK and thus no authentication was needed to get the content. |
That's not correct (in this case). curl performs preemptive authentication. It never sees the 401 in this case. I can give you any status you want from application code, it won't change the auth loop. Since the client initiated it (preemptively) the server will complete. This is what you see. See here:
Same URL, no preemptive authentication. Let's do
|
I see a similar problem. Not sure if it is the same.
Further notes:
|
This has been introduced a couple of months ago, I expressed my negative opinion about. RFC 72xx does not forbid preemptive authentication, but I see no point doing to if you hve Expectation header and early responses. |
curl has done unsolicited Authorization headers on first request since we first introduced support for Basic auth some two decades ago or so. That's not new. This particular bug might be new though, I don't know. |
We aren't talking about Basic here. It is solely SPNEGO. I can't remember the ticket by id, but there is one. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Still valid. |
While working on few issues in brandond/requests-negotiate-sspi which I haven't reported yet, I wanted to reproduce them with curl too and noticed that I can't because there is a severe bug.
I expect curl to signal me similar:
Which is bascially
SEC_E_INVALID_TOKEN
. I don't know the reason for the error yet, but this is not important for now.Next steps: Downloaded release tarball 7.69.1 and compiled on Windows 10 with MinGW.org GCC Build-20200227-1) 9.2.0 by passing:
mingw32-make mingw32-winssl-sspi
.FWIW: The backend is running Java 8 with JGSS.
Now run the curl command:
Why doesn't this fail? So I printed right after
curl/lib/vauth/spnego_sspi.c
Lines 242 to 252 in a6f7b2f
SEC_I_CONTINUE_NEEDED
), but I never see the continuation.The bug is right here:
curl/lib/http.c
Lines 4061 to 4064 in a6f7b2f
libcurl assumes that
*-Authenticate
can only occur on 401/407. After removing the status code check, I see:This one matches better:
Unfortuntely, this does not work on Un*x, there must be some other quirk in the code as well. Doing header prefix only, I get from MIT Kerberos:
But still authentication errors do not bubble up the chain so I never know that the authentication has failed for a severe reason.
This looks like a severe bug to me. What now?
PS: I am quite certain that the completion does not happen with MIT Kerberos too.
The text was updated successfully, but these errors were encountered: