On 01.05.2020 23:24, Peter Wu wrote:
> I wrote a script to do that and documented its usage on
>> http://b.poc.fun/sslkeylog-for-schannel/. It is in now way generic
>> (yet), but I successfully use in my research. Feel free to give it a go!
>> The main problem really is to get crandom and correlate it with master key.
> Thanks, right now I cannot test it but I'll keep this as reference!
>
> As for the linking with a session, if obtaining the Client Random is too
> complicated, but a ClientHello.SessionID is available, consider using
> the "RSA Session-ID:" format as done by the earlier SChannel work [1].
I think I've found an alternative way get the client random in a more
reliable way. Preliminary testing is promising, but I'll need some
additional time to flesh out the details.
> Since it relies on undocumented structures, maybe you could make an
> automated test that you run with GitHub Actions to check whether it
> keeps working? That can act as usage documentation as well.
Some automated testing is a good idea, not sure how applicable would GH
Actions be, because this probably needs to be eventually tested across
multiple different versions of windows...
>
> (Aside: maybe you can slap a Let's Encrypt certificate on your domain
> and make it available over HTTPS?)
Thanks for the heads-up, enabled https back.
>> It is currently win-10 only, TLS1.2-only, does not work with resumed TLS
>> sessions and poorly handles simultaneous connects.
> With TLS 1.2, it resumes with the same master secret. So as long as you
> have extracted the master secret from previous sessions, you should be
> able to use the same master secret if you combine it with the Client
> Random from the second session.
By the way, if wireshark sees both the original handshake and the new
resumed one, but the keylog file only contains master key for the first
client random, I assume it will still decode the resumed session correctly?
My current understanding is that as I'm hooking the key creation
procedure in lsass, it is not triggered during a resumption, because the
key does not need to be recomputed for resumption.
Also, for my testing it would be really nice to be able to quickly find
out from wireshark's ssl debug log if there was any session not
decrypted. Or, even better - is there a way to filter not-decrypted tls
in the UI?
