Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Friday, July 13, 2018 9:35 AM | 1 vote
Requests for SSLKEYLOGFILE functionality to be added to Schannel have been lodged with Microsoft via various channels but there is currently no support for this functionality. My favourite suggestion would be to make the information available via Event Tracing for Windows (ETW).
There are a few published hacks that allow the information to be obtained; two examples are: “Extraction of TLS master secret key in windows” (presented at 2016 International Conference on Information and Communication Technology Convergence) and “Extracting CNG TLS/SSL artifacts from LSASS memory” (Purdue University, Open Access Theses).
Both techniques depend on unfettered access to LSASS.exe and, assuming that Schannel secrets are protected by Credential Guard (when available and enabled), won’t work in some situations. The first approach injects code into LSASS, which is not something that I would routinely want to do. The second technique is “safe” (needs read-only access to LSASS memory) but is not coordinated with the creation and destruction of TLS secrets. Fortunately, the essential information (the TLS master secret) is associated with the SSPI credentials handle, as is the ability to resume a TLS session, so browsers typically keep these handles open (if one scans LSASS memory after browsing a site but before closing the browser then this technique often delivers the desired information).
A third approach is to use the SSPI ExportSecurityContext function; this exports a “serialized representation of a security context” and, whilst this data is notionally “opaque”, it is not obfuscated. It consists of a series of elements with a tag/length (allocated and used) header and the client and server write keys are easily identifiable (also as “opaque blobs” that can be imported via BCryptImportKey and exported as plain data via BCryptExportKey). The keys are wrapped in a small data structure (described in the Purdue paper) that just contains the TLS protocol version, the selected TLS cipher suite, the “write” key, an indication of whether it is the server or client “write” key and a field that either contains the GCM implicit nonce or the MAC key (for the CBC cipher suites).
This third approach does not reveal the TLS master secret, but it does make all of the information that is derived from it for TLS encryption purposes available. This is why I call it SSLKEYLOGFILE-like data (new keywords would be needed to describe it).
An SSLKEYLOGFILE needs more than just secrets and/or key material – it also needs information that identifies to which TLS connection the values belong. The TLS Client Hello random number is often used for this purpose. When establishing a TLS connection via calls to InitializeSecurityContext, all of the TLS handshake messages are available as either input to or output of this routine, so the Client Hello random can be easily obtained.
Very few applications use Schannel via the SSPI interface directly; many use WinINet, WinHTTP or .NET Framework HTTP classes and these interfaces don’t expose the underlying SSPI handles. More generally, few applications are extensible enough to allow the necessary data gathering to be integrated into their processing of TLS connections. One approach is to use the debugger API to monitor the input/output of InitializeSecurityContext and to direct the calling thread to execute ExportSecurityContext once the security context has been established. As a side note, the ETW provider for WinHTTP (Microsoft-Windows-WebIO) does log all of the inputs/outputs of InitializeSecurityContext so all that is missing from its ETW output is the ExportSecurityContext information.
One could argue that just monitoring the input of sspicli!EncryptMessage and the output of sspicli!DecryptMessage with a debugger is the easier way of viewing the plain text of a TLS connection but, with the increasing prevalence of HTTP/2, it is useful to be able to leverage the full decoding capabilities of tools like Message Analyzer when viewing the data.