[webpentest <webpentest@xxxxxxxxx>]

Hello list!
I wanted to share my progress on schannel session keys extraction.
First of all, I've written a two-part series that documents my efforts,
see [1] and [2]. They are rather lengthy and mainly focus on the
debugging and reversing parts.
Secondly, the current iteration of the tool ([3]) is able to extract
both TLS1.2 and TLS1.3 key material in the format digestible by vanilla
Wireshark at least on Win10 (but should work on any x64 windows) for
both client and server connection.
My experiments on schannel's experimental TLS1.3 support seem to show
that it currently lacks support for session resumption (see [2]), but I
I'm not quite certain if this is not something that I did wrong.

Any feedback on the tool and especially any feedback regarding schannel
+ TLS1.3 + session resumption is very much appreciated.

I'd like to thank Peter for continuous interest and for the links shared.

George.

[1] https://b.poc.fun/decrypting-schannel-tls-part-1/
[2] https://b.poc.fun/decrypting-schannel-tls-part-2/
[3] https://github.com/sldlb/win-frida-scripts/tree/master/lsasslkeylog-easy
On 19.06.2020 00:58, Peter Wu wrote:
> Hi George,
>
> On Thu, Jun 18, 2020 at 08:29:41PM +0300, webpentest wrote:
>> Hello again, Peter and wireshark-dev!
>>
>> While testing and extending my schannel-sslkeylog tool that I previously
>> mentioned in the list ([1]), I found that in some cases I'm currently
>> not able to reliably tie extracted master secret to a client random,
>> because of the TLS Session Hash being in use (a.k.a "Extended Master
>> Secret", see RFC 7627).
>> In these cases I can only currenty reliably get a pair of session_hash,
>> master_secret, but this format is currently not supported by wireshark's
>> keylogfile parser.
>>
>> I was wondering whether a patch implementing this kind of sslkeylog
>> format (e.g. SESSION_HASH <hash> <master_key>) would be considered for
>> inclusion into wireshark? The amount of changes needed seem to be rather
>> small -- much smaller than my previous patch we discussed.
> That sounds reasonable. The session_hash (hash over all handshake
> messages) can indeed easily be implemented in the current form. In fact,
> it appears that this is currently unconditionally calculated when the
> secret is not yet available.
>
> It could potentially be useful when the Client Random collides (in the
> Go crypto/tls test suite it is all zeroes).
>
>> Of course some workarounds exist and extracting a client secret or a
>> session id must be possible, but it probably would make my tool much
>> less portable, because the API that I currently hook (namely,
>> SslGenerateMasterKey[2] and SslImportMasterKey [3] from ncrypt.dll) is
>> at least partially documented and more or less stable, whereas
>> extracting client secret or a session id for sessions that use Extended
>> Master Secret would require tapping into less-documented and less-stable
>> schannel.dll APIs.
>>
>> Regards, George.
>>
>>
>> [1] http://b.poc.fun/sslkeylog-for-schannel/
>> [2]
>> https://docs.microsoft.com/en-us/windows/win32/seccng/sslgeneratemasterkey
>> [3] https://docs.microsoft.com/en-us/windows/win32/seccng/sslimportmasterkey
> Based on these two docs, I was not able to see where the session_hash is
> available. Would you mind elaborating on the (reverse engineered?)
> details? There are already a couple of formats, so ideally those can be
> reused. If not, then hopefully the proposed new addition covers this and
> future cases.