schannel Timeout Breaks CAC Authentication

[timomta]

I did this

The new time out introduced in this change broke CAC authentication for us: #19205

Our server is CAC authenticated, meaning there is a hardware device connected to the client machine, a card reader, which has a driver that prompts the user for the PIN for their CAC card so the certificate can be read from it. This process takes far longer than 7 seconds.

I expected the following

The old timeout allowed plenty of time for the driver to display the UI prompting for the PIN, and allowing for certificate retrieval/authentication from the card if the PIN was correct.
This affects our git client and Visual Studio.
Can you please make this value configurable rather than such a small constant if you do not want the large constant timeout?

curl/libcurl version

curl 8.17.0

operating system

Windows Server

[bagder]

This process takes far longer than 7 seconds.

So curl is in a blocking call "forever" so that there can be a UI popping up that asks for a PIN? That sounds crazy!

[timomta]

Not clear what you are trying to say. Are you saying that there should be no reason for a longer timeout for a person to respond to the pin prompt as it was before?

[dfandrich]

To me, it's surprising that the SChannel API can allow this to happen. Is there another equivalent API that you know of that is NOT blocking?

[vszakats]

/off

Crazy, but not unprecedented on Windows: CRYPT_SILENT prevents
this for CryptAcquireContext(). Headless servers are an afterthought
on this platform. Also in CI there are GUI popups waiting for a mouse
click, often without a clue in the log, just appearing hung.

[bagder]

Waiting for a PIN from a user can take a nearly infinite amount of time if the user happens to take a coffee break. Should we then just sit blocking in a call in case that happens?

[timomta]

Again, I'm not sure how we got to 'infinite' and 'forever'. There was nothing in my original ask regarding that kind of wait. I simply asked that it be configurable.

If I read the change or the code correctly, cURL has never waited 'infinitely' or 'forever', but it did wait a sufficient amount of time for a user to respond to a UI pin request and CAC hardware to respond with the user's certificate.
Reading your discussion on the issue, you chose an arbitrary amount of time, '7 seconds', without user data to back it up, stated that people would complain if it was a problem, and, if so, evaluate adjusting up appropriately.

We have a unique security situation where such a timeout is actually used due to a human in the loop. I suppose even a 1 to 5 min timeout would probably suffice, or configurable with an upper limit.

I'm hoping you'll consider the request.

[icing]

Since the duration is defined in one macro, you may patch the source to make it longer. Due to it being mainly used in US military applications, a budget for such extra work should not be a problem?

[timomta]

It'd be for any application that has a delay due to a pin, introduced by a CAC or smart card.

[bagder]

I think my point is that even if you set it to 10 minutes, that will occasionally be too short as well. Not to mention how it totally breaks libcurl applications using concurrent transfers.

To me, a more sensible approach would probably rather be to first fail the transfer in a defined way that tells the application that it needs something (like a PIN) to continue and then once it has the PIN it would do the transfer again and then not block.

[timomta]

I see. Honestly, I think if someone takes 10 minutes to respond, it is acceptable to timeout. Typically, folks using this type of hardware and ID are sitting at their desks in front of their computers. If they aren't, then I completely agree it should time out.

Thinking through the options then for these types of customers, is the thinking to push on the Windows schannel team or on the fork for Windows cURL? You may not know -- that's fine, just looking for where to go with customers in this situation if you feel it is too high of a risk for your team.

There is a chain of dependency here I'm trying to sort through. Visual Studio depends on the git cli, the git cli depends on cURL for its HTTP operations.

Thank you for the dialog.

[jay]

FWIW schannel renegotiation blocking is unlikely. What I mean by blocking here is waiting on the socket so other transfers can't be serviced. Some corner cases can cause that to happen up to the renegotiation timeout. Schannel renegotiate code "blocks" in that if it encounters one of those corner cases it won't kick up a CURLE_AGAIN for incomplete renegotiation but will instead wait for the socket and call the progress function every second. In the code I called it "partially blocking" behavior.

The macro name MAX_RENEG_BLOCK_TIME might confuse the situation a little. It was originally named max_renegotiate_ms. It's the maximum wait time in milliseconds for an Schannel renegotiation which may block.

I don't see much risk in reverting the timeout if it is causing problems.

[timomta]

If you'd be willing to do that -- THANK YOU!

In this conversation, there is also an underlying theme wherein you feel schannel is behaving incorrectly, or a protocol violation.
I do not disagree with you. This project is important, has clearly been forked, and included with the OS.
If you would be willing to submit a report to https://msrc.microsoft.com/report, under the Security Threats section, I believe it be very helpful, and great feedback to that team.
Even though it is labeled "Security Threats", it is still the place to report protocol violations.
They'll request this type of data:
Affected product and version (e.g., Windows Server 2019 / 2022, but in this case, the latest version)
Whether this is client-side or server-side TLS
Exact Schannel behavior observed
Event IDs, logs, or crash dumps
Repro steps (clean install if possible)
Expected vs actual behavior
Proof-of-concept or trace data if available

If they engage the dialog and you want to involve me with respect to this discussion, I will be happy to give them the data and scenarios I have collected that brought me here to file this issue.

In any case, thank you again.