-
Notifications
You must be signed in to change notification settings - Fork 140
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
Issue with DTLS 1.2 Session Resumption #183
Comments
The behavior you see is indicative of the TLS-Attacker not being able to decrypt the Finished message. Did you give TLS-Attacker the master secret so that it can correctly derive the keys? |
No, I am not currently providing the master secret to TLS-Attacker. Would it be necessary even if I am using a PSK (Pre-Shared Key) cipher suite, which is the case in my scenario? Additionally, I am using two separate workflows (one for each handshake). Could this setup potentially affect the session resumption process? If further details are needed, please let me know. Thank you for your assistance! |
Yes, a resumption handshake uses the previous master secret to avoid doing the key exchange again, even for PSK cipher suites. Doing two separate workflows is in general possible, but requires you to (at least) manually copy the master secret into the new connection (by adding the session parameters into the sessionList), such that TLS-Attacker can derive the keys for the connection. You can also do it in one workflow by using the |
Finally, it worked! I managed to resolve the issue using the |
I was able to achieve it by retrieving the session parameters from the first session and applying them to the second one. I would like to know if there is an alternative approach or if this is the only way. |
I am a bit confused. To do session resumption you somehow need to propagate the parameters from the one session to the other. This should be done automatically if you do it within one workflow. So I am unsure what you did/didn't do to make it work/not work. Can you provide a minimal example so that I can reproduce it? |
Not working case:TLS-Attacker Server
OpenSSL Clientopenssl s_client -connect 127.0.0.1:4433 -dtls1_2 -psk 316132623363346435653666 -sess_out /tmp/session.pem Obtained traceWorking case
OpenSSL Clientopenssl s_client -connect 127.0.0.1:4433 -dtls1_2 -psk 316132623363346435653666 -sess_out /tmp/session.pem Obtained trace |
Title: Issue with DTLS 1.2 Session Resumption
Description:
I am encountering an issue when trying to resume a previous DTLS session. I attempt this by setting the Session ID of the initial session in the Client Hello of the subsequent handshake.
Scenario:
Analyzing the generated network traffic, I observe that the server (using OpenSSL) responds correctly to facilitate session resumption.
To handle the expected response on the Attacker side, I use the following TLS-Attacker action:
trace.addTlsAction(new ReceiveAction(new ServerHelloMessage(), new ChangeCipherSpecMessage(), new FinishedMessage()));
Observations:
However, upon reviewing the TLS-Attacker logs, it appears that the FinishedMessage is not properly read, as only the ServerHello and ChangeCipherSpec messages are detected.
I would greatly appreciate any guidance or recommendations on how to resolve this issue. If further details are needed, please let me know.
Thank you for your assistance!
The text was updated successfully, but these errors were encountered: