steffengy / schannel-rs

Schannel API-bindings for rust (provides an interface for native SSL/TLS using windows APIs)
MIT License
49 stars 51 forks source link

Support SCH_CRED_NO_DEFAULT_CREDS flag on AcquireCredentialsHandleA #37

Closed elemount closed 7 years ago

elemount commented 7 years ago

Hi, I'm working on add windows SSL support for MySQL by rust-mysql-simple. And was blocked for the TLSv1.1 Server hello done and Client send cert. Without SCH_CRED_NO_DEFAULT_CREDS flag on AcquireCredentialsHandleA, schannel will pick a cert from current_user/local_machine cert store and send it. That is not expected and server will response BadHandshake. Must set the SCH_CRED_NO_DEFAULT_CREDS on the AcquireCredentialsHandleA can solve this problem.

Workaround patch is that in https://github.com/steffengy/schannel-rs/blob/master/src/schannel_cred.rs#L196 Change code to

cred_data.dwFlags = winapi::SCH_USE_STRONG_CRYPTO | winapi::SCH_CRED_NO_DEFAULT_CREDS;

Can you provide a way to set the SCH_CRED_NO_DEFAULT_CREDS flag on the schannel_cred::Builder ?

sfackler commented 7 years ago

We already pass ISC_REQ_USE_SUPPLIED_CREDS to InitializeSecurityContext, which seems like it performs a similar operation to SCH_CRED_NO_DEFAULT_CREDS but on a different function: https://github.com/steffengy/schannel-rs/blob/master/src/lib.rs#L60

Do you know what the deal is here?

elemount commented 7 years ago

Yes, I've read the code. But that are not same. I've tested it. Another example I've seen in Internet is that http://microsoft.public.platformsdk.security.narkive.com/uCxhmfV0/schannel-client-authentication-problem-with-optional-client-certificate .

steffengy commented 7 years ago

As I understand it, ISC_REQ_USE_SUPPLIED_CREDS disables automatic certificate-picking and SCH_CRED_NO_DEFAULT_CREDS automatic certificate-chain building.

Older versions before schannel support was removed of chrome use both. Some implementations such as CURL only ISC_REQ_USE_SUPPLIED_CREDS. (As a weird example, CoreFX which is comparatively low-level only passes SCH_CRED_NO_DEFAULT_CREDS)

Passing both flags should be fine in my opinion. We might have to perform additional work for using client certificates, which could be determined by comparing different implementations (such as both examples mentioned above).

elemount commented 7 years ago

Attach another link which explain the SCH_CRED_NO_DEFAULT_CREDS(http://www.cnblogs.com/shipfi/archive/2008/10/13/1310358.html) and

 This flag is intended for use by client applications only. If this
 flag is set, and the server requests client authentication, then
 schannel will *not* attempt to automatically acquire a suitable
 default client certificate chain. This flag is ignored by non-NT5
 versions of schannel, but all client applications that wish to
 manually specify their certicate chains should specify this flag,
 so that there's at least a chance they'll run correctly on NT5.
sstecko commented 7 years ago

I would like to double down on this issue. We had an issue with the current configuration presenting credentials even though none were supplied. Switching the flag as suggested in the initial post of this issue fixes the problem.