-
Notifications
You must be signed in to change notification settings - Fork 573
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
add callback to export secrets for SSLKEYLOGFILE #4043
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for taking this up! No objection to add this functionality, in general. I just added a few suggestions for simplification, pending the opinion of @randombit.
A few more general remarks:
- Consider renaming
TLS::Callbacks::tls_ssl_key_log_data()
to...::tls_log_secret()
- The test cases in
src/tests/test_tls_rfc8448.cpp
are well-suited to verify this new callback; they feature some hard-coded TLS 1.3 traces as specified in RFC 8448. I can take this task, as it will likely require some additions to the test's already intricate architecture.
(Edit: I ended up extending the unit test intest_tls_cipher_state.cpp
instead) - Optional: Add an example (in
src/examples
) that uses the callback to actually emit a file stream formatted as specified in draft-thomson-tls-keylogfile-00
7f1e5a2
to
6037524
Compare
@reneme I took all your suggestions into account. I just have to add an example. Please, review once more |
6037524
to
6245d61
Compare
I have added example. Waiting for review. |
Thanks! I'm off currently on vacation. I'll do my best to review next week. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems fine to me to add this functionality. I left a few comments wrt documentation and the policy. @reneme has touched TLS at more more than I in recent times, so I'd like his approval on the overall change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
General Remarks and Extension
I iterated on your proposal to have Client/Server_Impl_13
derive from an abstract callback class to encapsulate the dependency on the HandshakeState
and Callbacks
as well as Policy
. I mostly moved the definition of said class into tls_channel_impl_13.h
and cleaned up some unnecessary casts.
Also, I extended the test in test_tls_cipher_state.cpp
to not only mock the logging calls but also to verify that the expected secrets were logged (as they are defined in RFC8448). Please cherry-pick (and perhaps squash) my commits into this pull request: https://github.com/reneme/botan/tree/ssl_key_log_file.
Missing Functionality: Key Update
Currently, this implementation does not log secrets when a key update is performed. See section 3.1 of the draft:
Key updates (Section 7.2 of [TLS13]) result in new secrets being generated for protecting application_data records. The label used for these secrets comprises a base label of "CLIENT_TRAFFIC_SECRET_" for a client or "SERVER_TRAFFIC_SECRET_" for a server, plus the decimal value of a counter. This counter identifies the number of key updates that occurred to produce this secret. This counter starts at 0, which produces the first application data traffic secret, as above.
The key updates are handled in the Cipher_State
class as well (see update_read_keys()
, update_write_keys()
); hence, supporting CLIENT/SERVER_TRAFFIC_SECRET_N
(with N > 0
) should be easily doable. Could you take a look at this @volok-aleksej?
158d0ab
to
65dc230
Compare
fixed build of test of sslkeylogfile updated some function description reverted default value of Policy::allow_ssl_key_log_file to false
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @volok-aleksej! The patch looks good to me now, except the extension of Policy::print()
as detailed below.
Repeating (for future reference): The TLS 1.3 key update currently does not produce a CLIENT_TRAFFIC_SECRET_N
and SERVER_TRAFFIC_SECRET_N
. This could be done as future work.
Ок. I'll do it. In progress. |
@reneme I've added key update logging ( |
4ff9396
to
98d75cc
Compare
Nice! Thank you. I took the liberty to adapt your implementation somewhat. Please replace your last commit with this one: reneme@f3eae3c and squash your history. Then this should be ready to go. |
LGTM though I also prefer @reneme's approach on the last commit |
…ECRET_N where N>0) Co-Authored-By: René Meusel <[email protected]>
98d75cc
to
caa04f4
Compare
@reneme thanks. I've replaced last commit. Waiting for @randombit. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome! Thanks a lot for your contribution.
@randombit I cannot merge, presumably because your last verdict is "changes requested". Please go ahead once you're happy with the patch. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @volok-aleksej LGTM
in according with this document, i add callback to export secrets for SSLKEYLOGFILE