Wireshark-dev: [Wireshark-dev] Support for TLS1.2 decryption using derived keys
From: webpentest <[email protected]>
Date: Thu, 30 Apr 2020 10:37:49 +0300
Hello list,

I'm currently working on implementing a SSLKEYLOGFILE-like functions for
TLS connections that use Windows SChannel APIs (e.g. IE/Edge, as well as
other windows apps such as RDP client). SChannel does not expose its
keys, though some research was done on recovering them (see [1] and [2]).

I won't describe here the inner workings of schannel and key isolation
in Windows, but the bottom line is as follows:

1. The master key is only available to the lsass.exe process and
accessing it thus requires elevated privileges. Furthermore, there might
be additional restrictions that prevent event admins from accessing the
memory of lsass.

2. The derived keys, however, are available to the actual process that
uses schannel. Notably, I can extract the client and server write keys
and IV's, as well as the client random (see section 6.1 of RFC 5246,
page 17).

This means that it is possible to decrypt schannel traffic without the
need for elevated privilege, by extracting and using those derived keys,
but wireshark currently lacks the ability to ingest these values from a
keylog file. Currently it can use derived keys for decryption only for
TLS1.3 connections (see [3]).

I've thrown together a quick and dirty implementation of using derived
keys to decrypt TLS1.2 (see [4]) and verified that it works: with the
keys that I extracted I was able to decrypt successfully the RDP
connection that I made from a windows client.

So, now my question is as follows:

1. Considering the limited use-case for this functionality (using
derived keys to decrypt TLS1.2), does it have a chance of being merged
into upstream?

2. If yes, is there a person familiar with wireshark's tls dissector,
who is willing to advise me on what is the best way to implement these
changes? I'm ready to spend time on reimplementing the patch, but I'll
need someone for guidance and review.


George Noseevich.



[3] https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12779#c17