Wireshark mailing list archives
Re: Support for TLS1.2 decryption using derived keys
From: webpentest <webpentest () gmail com>
Date: Sat, 4 Jul 2020 15:03:51 +0300
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/sslimportmasterkeyBased 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.
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- Re: Support for TLS1.2 decryption using derived keys webpentest (Jul 04)