I've been studying the various cryptographic APIs on Windows, and the flow that Windows goes through when an application creates an SSL connection.

One of the APIs I've come across are the CNG SSL Provider Functions (e.g., SslExportKey, SslImportKey, SslGenerateMasterKey, etc.). Many of these APIs require the caller to pass an SSL protocol provider in the first argument.

My question is, are these APIs only ever called by Windows during an SSL connection (I've noticed lsass.exe calls a few of them)? Or, is it possible for any application to call them, and if so, how would such application obtain a handle to the SSL protocol provider? I've noticed there is NCryptOpenStorageProvider, however, none of the provider names refer to an SSL one. I guess what I'm trying to find out is if these APIs can ever be called outside of an SSL connection context.

My other question is, are these SSL APIs only called after Windows verify that the SSL certificate is valid?

1 Answer 1


This is technically a programming question, not a security question, but it gets deep enough into the weeds of Windows CNG that I'll answer here rather than voting to move.

The function you're looking for is SslOpenProvider, which uses the same NCRYPT_PROV_HANDLE type that NCryptOpenStorageProvider does, but works with Crypto API Next Generation "SSL providers" rather than "storage providers". Note that you can install your own SSL provider (just as you can install your own storage provider), but the default provider returned by SslOpenProvider is Microsoft's own SChannel, implementing the cipher suites that Microsoft provides. To get the list of installed SSL providers, use SslEnumProtocolProviders, and iterate over the returned array's names and comments.

You can indeed call these functions yourself, if you want to implement a TLS client or server instead of using the one built into Windows (SChannel), or if you want an existing client or server to use a non-default provider. Because you're implementing your own client/server, you would be the one making decisions about how to implement things like certificate validation, cipher suite selection, handshake logic, and so on (you'd essentially be replacing SChannel). Of course, you might reasonably use a key storage provider and/or the built-in Windows certificate APIs such as CertCreateCertificateContext to work with certificates and their private keys. This could also be used for implementing things that aren't exactly SSL/TLS, if you wanted (either new / experimental protocols, or other secure communication protocols).

However, you also might write your own implementation(s) of these functions (or wrappers around implementations in e.g. an external TLS accelerator device), package it into your own CNG SSL provider, and expect the existing Windows libraries to call your provider (either because the client/server application requested it, or because you made your provider the default, or because you're using a cipher suite that only your provider offers). Note that, at present, there's a lot of overlap between CNG SSL providers and CNG algorithm providers, such that e.g. SslVerifySignature is apparently not currently used by Microsoft's TLS server implementation, and instead it calls NCryptVerifySignature (the CNG generic function for verifying asymmetric digital signatures). Providers do have to implement the full API, but can simply wrap functionality exposed by other providers for anything they don't want to provide their own implementation of.

The CryptoAPI Next Generation (CNG) architecture in Windows uses pluggable "providers" to implement nearly all functionality, rather than hard-coding implementations. These providers are divided into various types, such as algorithm providers (implementing primitives such as ciphers and hashes, and constructions such as modes of operation or HMAC), key storage providers (used for hardware- or software-based storage and handling of cryptographic keys, including the private keys for certificates), and SSL providers (implementing full cipher suites as used in various SSL/TLS protocol versions). Providers don't implement things like certificate handling or movement through the TLS state machine. Instead, they handle slightly lower-level behavior such as key exchange and derivation, and encrypting or decrypting packets. These behaviors may in turn be delegated to lower-level providers that implement the actual primitives and constructions.

Thus, Windows certainly does call (some of) these functions, any time SChannel is used to establish a TLS connection from the client or the server side. Having Windows' TLS implementation sort of "talking to itself" across the consumer/provider line of CNG may seem strange, but it makes a lot of sense when you consider that e.g. you might want to offload certain operations to dedicated accelerator hardware, while keeping most of the actual TLS logic in the existing library.

  • Many thanks for the detailed answer. I have some follow up questions please. Given that these can be called by any custom provider, and given that I believe Microsoft only accepts signed/trusted providers to be installed, is it valid to assume that these APIs will only be called from trusted providers with trusted SSL public/session keys? I'm trying to intercept these calls for an experiment (using Microsoft detours) and extract SSL keys but wasn't sure if my approach is reliable if anyone can call these APIs.
    – Kakalokia
    Commented Jul 3, 2022 at 8:16
  • Secondly please, even with a custom provider, would it be always lsass.exe calling these APIs, or can lsass.exe be bypassed during an SSL connection? Hope my questions make sense :)
    – Kakalokia
    Commented Jul 3, 2022 at 8:17
  • For more context, I'm attempting something similar to b.poc.fun/decrypting-schannel-tls-part-1 , but I'm interested in how much trust I can place in the data received by the SSL provider APIs. For example would a session key received in SslImportKey be always one generated during a trusted SSL connection/session.
    – Kakalokia
    Commented Jul 3, 2022 at 10:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .