-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow loading of session secrets directly #64
base: master
Are you sure you want to change the base?
Conversation
actually thats a pretty handy extension adding support for NSS Key Log Format logfiles (generic to NSS based applications). Since a sessionctx describes one specific session, would it make sense to have a keystore class that takes care of loading the various formats (rsa, keylog, ..) that provides interfaces to the sessionctx to query for a secret based on the client_random, rsa_pubkey, .... Would probably make the code more readable and move all the key loading stuff to a separate class. what do you think @alexmgr ? like:
|
Oh hey, so that format does have a name. It looks like wireshark uses an extended version (allowing pre-master secrets as well). I can't find any kind of real spec for it. Regardless, I think I'd like to support everything wireshark does. I like the idea of having a separate keystore type. Are you imagining a custom format for |
+2 on this proposal, makes a clear distinction between TLSContext and keys. We probably want TLSKeyStore properties to be settable only once, when a user specifies the TLSKeyStore explicitely. This would avoid having a whole bunch of conditionals in TLSSessionCtx(), and allow an unconditional set. @ALSchwalm I believe, what Tin is proposing is an interface for it. Something in this spirit:
|
3b7d120 untested is more or less a braindump of the keystore I had in mind. It is implemented on top of @ALSchwalm changes (thx!).
any thoughts? |
Wireshark has an option allowing the user to directly load (pre-)master secrets for decryption. This is useful both because it allows the user to review decrypted traffic captures without having the server's private key available, and also when the cipher suite choice would make it impossible to decrypt the traffic even with the key (i.e., with DH) . Several programs can already generate output in the format wireshark requires, such as firefox and chrome.
This patch adds a function
load_secrets_from_file
that accepts files in this format. The format is not well documented (the official wireshark docs refer to this stack exchange comment). The format is best described by a comment in the wireshark source here.If you are interested in merging this, I can add some tests.