On Sat, May 02, 2020 at 01:48:12AM +0300, webpentest wrote:
> > 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...
Based on https://github.com/actions/virtual-environments, it looks like
Windows Server 2016 and Windows Server 2019 are supported. There are
other CI platforms such as AppVeyor, they offer Windows Server 2012 R2,
2016 and 2019: https://www.appveyor.com/docs/windows-images-software/
I'll leave it up to you to figure out a CI platform. Worst-case, you
don't have regression tests for older platforms. Best case, you catch
issues with newer platforms. And in any case, you could keep a local
fleet of machines and run the same automated scripts :-)
> > 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?
Correct, Wireshark will associate the Session ID (or session tickets, if
there are any) with the master secret. It basically implements what a
normal client would do for session resumption.
> 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.
That sounds reasonable, all that lsass would have to export is a session
ID or session ticket. Maybe you can extract these and use the "RSA
Session-ID:" format I mentioned before? (And "RSA" is really a misnomer,
it is independent of the key exchange.)
> 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?
The Finished message is normally encrypted, you could match that as
quick test:
tshark -r your.pcap -otls.keylog_file:keys.txt -Ytls.handshake.verify_data
These are usually directly sent together with the ChangeCipherSpec
message. Assuming that is the case, then the following filter will show
non-empty output if there are sessions that fail decryption:
tls.change_cipher_spec and not tls.handshake.verify_data
Example info column for that case (tshark -Tfields -e_ws.col.Info ...):
Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
Change Cipher Spec, Encrypted Handshake Message
Example info column for the case where decryption succeeds:
Client Key Exchange, Change Cipher Spec, Finished
Change Cipher Spec, Finished
Hope it helps!
--
Kind regards,
Peter Wu
https://lekensteyn.nl