Pass ISC_REQ_USE_SUPPLIED_CREDS to InitializeSecurityContext

[jethrogb]

Fixes #23. As mentioned in there, not sure if this is the behavior you want.

[sfackler]

From the documentation, it sounds like this flag may not solve the problem described in #23?

When this flag is specified, Schannel will return SEC_I_INCOMPLETE_CREDENTIALS to the client when the server requests authentication and the client has not previously supplied a certificate.

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

[steffengy]

@jethrogb's testing and common usage such as https://github.com/curl/curl/blob/07fd7871b38cc8472c3806e254ba4062e3adeae0/lib/vtls/schannel.c#L594

seems to indicate that the documentation is off (once again).

[sfackler]

We would need a similar check for that error code, right: https://github.com/curl/curl/blob/07fd7871b38cc8472c3806e254ba4062e3adeae0/lib/vtls/schannel.c#L592

[steffengy]

In short, If we want the same behavior, yes.

Behavior 1 CURL

• First attempt to connect the server, leaving users certificates to schannel (which will look through several stores trying to find something that might work and sending it to the server)
• If the connection fails with SEC_I_INCOMPLETE_CREDENTIALS, pass ISC_REQ_USE_SUPPLIED_CREDS to prevent SCHANNEL from sending any certificates (since it/we do not pass any to it).

==> Potentially unwanted that certificates are sent automatically?

Other behavior (as of this PR)

The more sensible alternative would be to rely on ISC_REQ_USE_SUPPLIED_CRED for all cases. This would apparently only send the certificate associated with the acquired credential handle.

We already pass certificates to AcquireCredentialHandle so this behavior should also work out of the box (not sure if client auth is/was used before).

Not really having any hard opinion on this, actually pretty unsure what the best tradeoff is.

[sfackler]

Ah, right, misread that check. LGTM