http.sys, schannel and TLS client certs

NTDEV
1

For any consumer of http.sys (be it IIS7.5 unmanaged code, a self hosted WCF service, or some dotNET socket using .NET SSL classes), how do i REMOVE the dependency on windows cert stores - when ACCEPTING the client cert in the SSL handshake?

My project has the browser (or any other https client) provide self-signed client certs (and certverify signatures) to the http.sys endpoints using the usual SSL/TLS SSL handshake protocol. Its all perfectly normal - except that the self-signed client cert is UNKNOWN to any windows cert store. Its NOT a PKI-centric solution/protocol, that is. The cert is not rooted in a root/enterprise trust store, and the cert is NOT present in the trusted people store. The cert is simply not known about, before the SSL handshake commences. SSL handshake needs to simply verify the signature, and pass up the cert blog to a higher layer (user space, IIS script, etc).

(The project is a formal W3C incubator research effort, FYI, intending to push the envelope).

There may be dollars available if its possible to insert a driver/interceptor int the kernel that should change the https.sys behaviour of SSL client certs (and cert store lookup, and any use of wintrust API). We bascially want/need to TURN off the higher assurance ontrols of windows/shcannel/http.sys, allowing the service endpoint to make its OWN trust decisions - using alternative technologies to PKI under development.

we are still very hazy on the scope of all this. We dont know if it’s shcannel that is imposing the cert store andor wintrust dependency (and perhaps shcannel in kernel mode can be tweaked) or http.sys. thus, we dont even know IF a drive could intercept and alter behaviour. For obvious reasons, one would want that driver signed!

2

> […] we are still very hazy on the scope of all this. […]

W3C’s WebID implementation on Windows is blocked by this issue.

Is there anyone who can help them understand how to integrate WebID
properly into Windows? (It might be that they’re not asking the right
question yet.)

Some background on W3C WebID:
http://en.wikipedia.org/wiki/WebID
http://www.w3.org/2005/Incubator/webid/

Some background on this particular question:
http://lists.w3.org/Archives/Public/public-xg-webid/2011Dec/0175.html

Thanks very much for any help!

Lee

3

For background on my issue:

my Nt4-era (yes pre win2000 knowhow!) understanding of the architecture is this.

a system driver or socket filter could setup security behaviours for a given endpoint. Today, we typically all only use http.sys (and the days of inserting one’s own winsock filter doing the SSL protocol engine are long over).

If the http.sys endpoint is configured for ssl (and requiring client certs options), various wrappers (SSPI, etc) around the schannel provider eventually construct an SSPI mechanism - a schannel instance that duely ties into the low level stack.

What I remember was that schannel delegated to wintrust (and its current provider) to find and verify cert chains - such as the n-element cert chain received from the wire. This is the point at which DISCOVERY is attempted, merging the certs inbound from the wire with certs in the intermediate and root stores. One discovered (ie. the chain closes to a root), then one walks the chain verifying each signature in turn (and any X.509 field/schema constraints, like requirement concerning overlapping dates on certs, cross certs etc etc etc, basicConstraints restricts paths to 3 elements or less, certs ahve the certSigning key usage bit setl etc etc)

Now schannel the protocol engine (an SSPI mechanism recall) also delegated to a particular cryptoAPI provider - the schannel CryptoAPI provider. This differed from all the other providers (e.g. enhancedRSA) because it supported particular hmac and KDF algorithms used SPECIFICALLY by the SSL handshake protocol (and one needs access to SSL state to compute said values). Of course, the whole point of delegating to CryptoAPI was so one could swap out and use HSM PCI cards …rather than the software crypto.

Now, FROM WHAT I HEARD (i.e. hearsay), the wintrust *provider* used by the schannel instance constructed by http.sys also uses code in the schannel *cryptoAPI provider* (the software crypto for SSL built into windows). That is, trust provider is delegated to the same per-SSL cryptoAPI DLL as is specifically providing implementon of those specific crypto primitives required by SSL/TLS.

So, its been my long term assumption (remember I see no source code…) that the model was as above. Things do make sense, in such a world view ; since now the cert stores and REQUIREMENTS for certs during chaing discovery can differ - by protocol stack, and by hardware crypto. When using an schannel-class HSM, the HSM can be delivering the “physical” cert stores. Furthermore transport security can being doing X (when handling crypto and trust assurances), while message security in user space can be doing Y (more flexible and allowing user code to override).

4

> If the http.sys endpoint is configured for ssl (and requiring client certs options), various wrappers

(SSPI, etc) around the schannel provider eventually construct an SSPI mechanism - a schannel

Are you sure http.sys can do SSL? I think it requires a user-mode helper service for this.

Also - is there any ways of adding your own branch to the Windows cert store?

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

5

Pre IIS7, one particular consumer of http.sys (i.e. w3svc) did indeed use the lsa user-mode process, by default. It used it for particular purposes (including determining which NT account a client cert should bind to, when minting an NT token that would power the thread executing some web script or NTFS page access. The code hosted in LSA (in IIS6) was the code originally hosted in the w3svc interceptor chain (an old umanaged “ISAPI”) in yet older IIS architectures. Lets not forget just how old IIS is (and how much it evolved, over the years). In IIS7.5, the option to use the LSA is removed. The entire SSL (vs https) protocol handling happens in the kernel, or kernel-loaded libraries (sspi/schannel/cryptoAPI/NGCrypto) operating in the right privileged ring. You can configure an ssl endpoint in the kernel (https.sys) even if iis is not a loaded feature in the OS - so the very notion of inbound cert -> NT account does not exist. but, this is missing the point (I THINK). Only once the client cert has been discovered and then verified … is it THEN presented to (such as) the LSA for client cert to NT account mapping. Token minting for access control in user mode processes happens way after the SSL handshake is over. AS it stands, I cannot get the kernel to even complete the handshake (and indicate the client cert blob to its service access point) since the handshake is (correctly, and conformantly) aborted by the protocol engine itself. The blob never GETS out of the kernel! this thinking has me wondering if I should go and dust off two REALLY OLD SSL (ethernet-based) FIPS 140-1 level 3 HSMs I have in my garage, doing nothing. But, the WERE built in the 2002 era for NT. Perhaps reverse engineering their binary drivers and the style of the config scripts will give a clue if their cert stores (stored in NVRAM/flash within the HSM) was driving the SSL discovery and chaining processes, vs using contents of the registry-based cert stores we see, normally. If it is, evidently I would need to built a “VIRTUAL HSM” that uses its own cert store for client cert “discovery” (and “always” finds, for all possible arguments).> From: xxxxx@storagecraft.com

Subject: Re:[ntdev] http.sys, schannel and TLS client certs
Date: Mon, 19 Dec 2011 07:57:06 +0400
To: xxxxx@lists.osr.com

> If the http.sys endpoint is configured for ssl (and requiring client certs options), various wrappers
>(SSPI, etc) around the schannel provider eventually construct an SSPI mechanism - a schannel

Are you sure http.sys can do SSL? I think it requires a user-mode helper service for this.

Also - is there any ways of adding your own branch to the Windows cert store?

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

6

Peter - I see a couple of options for prototyping this. The first is to build a custom socket listener that accepts any client certificate. That in turn could be used as a platform for implementing the WebID trust decision behavior on Windows (basically, break the problem in half). It also might help in getting the creating juices flowing for how to solve the connection problem system-wide.

As an aside, since IIS distinguishes between Accept and Require client certificates, there may be other games we could play in that context. But again that doesn’t solve the system-wide problem.

Regarding the latter, few possibilities to explore:

  • Pluggability in crypt32 chain building and recovation checking. Here’s documentation regarding the latter: http://msdn.microsoft.com/en-us/library/ms995348.aspx. Unfortunately, when the client cert doesn’t chain at all, there’s probably no revocation check. But maybe there is, and maybe chain building is pluggable too.

  • If not, another option is to intercept inbound TCP in the Windows Filtering Platform (WFP). Such a WFP filter driver would look for the client certificate (hopefully we’re not encrypted by that point), pend the flow, pop out to user, explicitly trust that cert (and/or do other WebID trust processing), then unpend the flow.

  • Another option is to explore the SSL protocol provider API in Crypto API (CNG, specifically). However, I think the client cert trust decision is actually made by the schannel package in SSPI, in which case CNG won’t help us.

  • So therefore another option is to implement a custom version, or maybe just a shim, of schannel

Let me know if any of those options sound palatable to you and worth exploring further.

7

thanks dan. the WFP path is something I can look at (since its a new concept to me). I was hoping that some kind of modern interceptor framework existed (beyond installing winsock hooks, as in 15 years ago). http://yorkporc.wordpress.com/2011/12/18/use-a-user-mode-implementation-of-ssl-to-do-complete-webid-model/ shows (in my summary) someone has already done option 2. Its my blog post summarizing code from gmx.de that wraps many of the windows features (cert stores, sspi ASN.1 decoders, cryptoAPI schannel support), with a custom SSL/TLS protocol engine. If nothing else is possible, we could go that track, but it is a most unsatisfying solution - as the SSL protocol engine is now in user mode. Its not “native windows”. None of the benefits of the assured platform for crypto and transport security are brought to bear then. Im not sure the ultimate customer would put up with that, since its easier to just install tomcat … and run it on a windows box! They are all the same level of unassured solution. Part of W3C claim for their design (desired claim, perhaps) is that it requires only bog-standard SSL - on your typical web server. And, we are finding that bog-standard NATIVE SSL in windows supporting IIS and any other container on win32 or posix/unix mode delivering http cannot do what they want, as the old-fashioned trust chaining rules of the PKI world are essentially BUILT IN to the “native” SSL delivered to IIS by http.sys. One cannot get the kernel to do client authn and either pass up the certs to a server-side user-mode script (post usage), or call out to a user mode interceptor (pre usage). one cannot do it… AS … its good design not to do or even ALLOW what I NEED to do. Unfortuantely, that means windows is cut out of the list of systems that “natively” support the protocol!
> Date: Mon, 19 Dec 2011 12:30:13 -0500

From: xxxxx@jwsecure.com
To: xxxxx@lists.osr.com
Subject: RE:[ntdev] http.sys, schannel and TLS client certs

Peter - I see a couple of options for prototyping this. The first is to build a custom socket listener that accepts any client certificate. That in turn could be used as a platform for implementing the WebID trust decision behavior on Windows (basically, break the problem in half). It also might help in getting the creating juices flowing for how to solve the connection problem system-wide.

As an aside, since IIS distinguishes between Accept and Require client certificates, there may be other games we could play in that context. But again that doesn’t solve the system-wide problem.

Regarding the latter, few possibilities to explore:

  • Pluggability in crypt32 chain building and recovation checking. Here’s documentation regarding the latter: http://msdn.microsoft.com/en-us/library/ms995348.aspx. Unfortunately, when the client cert doesn’t chain at all, there’s probably no revocation check. But maybe there is, and maybe chain building is pluggable too.

  • If not, another option is to intercept inbound TCP in the Windows Filtering Platform (WFP). Such a WFP filter driver would look for the client certificate (hopefully we’re not encrypted by that point), pend the flow, pop out to user, explicitly trust that cert (and/or do other WebID trust processing), then unpend the flow.

  • Another option is to explore the SSL protocol provider API in Crypto API (CNG, specifically). However, I think the client cert trust decision is actually made by the schannel package in SSPI, in which case CNG won’t help us.

  • So therefore another option is to implement a custom version, or maybe just a shim, of schannel

Let me know if any of those options sound palatable to you and worth exploring further.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

8

sigh.

when using hotmail (latest “fix”) to respond to lists, all the ebd iof line marks are stripped out by some or other agent in the path. After 15 years working fine on 100 exploder lists, now it doesnt.

I’m reduced to using a web form on osr online…

we still cannot negotiate syntaxes and character sets… properly, after 50 years of standardization. In 1943, folks could do remote job entry over 20kps circuits, sending teletypes messages from london to remote cryptobombes in downtown washington (or Ohio). But, today, I cannot send an email, reliably.