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.
--
Kind regards,
Peter Wu
https://lekensteyn.nl