DTLS decryption and UDP streams
Hello everyone
Im currently trying to dissect a WebRTC packets, encrypted with DTLS. I'm using the SSLKEYLOGFILE env variable method for decryption (so the pre-master secret gets dumped and then feeding this file to wireshark).
My problem is the following: Not all packets are getting decrypted. Upon further inspection, found out this could have to do with the way Wireshark follows the streams.
At some point in the communication, there is a change which cause some of the messages to start using a different dst port for UDP. Wireshark then thinks of these messages as belonging to a UDP stream that begins with the stun message that caused this port change, as opposed to with the handshake. My guess is that, since master secret is computed using the pre master secret and the client and server randoms, Wireshark stops being able to decrypt these messages, as it can no longer tracks them back to the original handshake.
My question is, is there any way for me to tell Wireshark that these messages also originate on the same handshake? I'm not sure I can fix the change of port, since that happens on code I don't have ownership upon.
Wanted to share images of the streams, but I dont have enough points xD (sorry)
Can you share a sample capture? (place on a file sharing site like DropBox, OneDrive, Google Drive, ...)
Also, if you search for "webrtc" here on the Ask site there are two other similar questions.
Is it possible that communication switches to a library or app that doesn't support SSLKEYLOGFILE?
Yes of course, here they are:
Full capture, with both the decrypted and non decrypted packets: https://drive.google.com/file/d/1z6E0...
Other following the UDP stream of decrypted (see how they reach the handshake): https://drive.google.com/file/d/19NnJ...
And last of the non decrypted UDP stream (they do not reach the handshake): https://drive.google.com/file/d/10gfD...
I really believe the problem lies here, since its the only difference on the packets. Also, the handshake is where Wireshark obtains the client and server random (so if it cannot reach a handshake from any particular packet, it would make sense for me that it would be unable to decrypt said packet).
I dont think so. The whole time the server uses OpenSSL, and I set it up so ...(more)
Can you make the files public on Google?
So sorry, thought they were. Here they are public
Full capture, with both the decrypted and non decrypted packets: https://drive.google.com/file/d/1z6E0...
Following the UDP stream of decrypted (they reach the handshake): https://drive.google.com/file/d/19NnJ...
Non decrypted UDP stream (they do not reach the handshake): https://drive.google.com/file/d/10gfD...
Thanks and sorry for the inconvenience!
Are there capture files to go along with the screen shots?
Is there a proxy involved? Source and destination addresses are the same (for both IPv4 and IPv6).