SSLKEYLOGFILE for WebRTC DTLS, Wireshark cannot find master secret

152 views
Skip to first unread message

Juan Navarro

unread,
Jun 3, 2024, 3:10:54 PMJun 3
to discuss-webrtc
Good day,

I'm trying to use the SSLKEYLOGFILE mechanism of Chrome/Chromium in order to inspect some WebRTC DTLS packets with Wireshark. In theory these are SCTP messages, but that's exactly what I want to check and verify by decrypting and inspecting them.

I followed Using the (Pre)-Master-Secret. However, it doesn't work for WebRTC DTLS, and I'm having a very hard time finding online discussion specifically about this use case.

To my untrained eye, the problem seems to be that Chromium is not printing the appropriate identifiers in its own TLS keylog, so Wireshark obviously cannot find them to decrypt the packets. Is that the case, or I am missing some configuration, maybe?

I made a capture with Wireshark, containing 2 Client Hellos, and none of the random values can be found among all the CLIENT_HANDSHAKE_TRAFFIC_SECRET and CLIENT_TRAFFIC_SECRET_0 entries of the keylog file.

This is what I'm running:
  • Ubuntu 22.04
  • Chromium 125.0.6422.112 (Official Build) snap (64-bit)
  • Wireshark 4.2.5

And the order of execution is as follows:

1. Open Chromium. I use this command for development:

    export SSLKEYLOGFILE="/path/to/keylog.txt"

    /usr/bin/chromium-browser \
        --user-data-dir='/tmp/chromium-profile' \
        --guest \
        --no-default-browser-check \
        --auto-accept-camera-and-microphone-capture \
        --use-fake-device-for-media-stream \
        --enable-logging=stderr \
        --log-level=0 \
        --v=0 \
        --vmodule='*/webrtc/*=2,*/media/*=2,tls*=1' \
        http://localhost:4200/


2. Start Wireshark capture on device lo (this all runs on a local dev machine).

3. Start a send-only publication from my page (it's just a WebRTC app with a "Start" button) to a local WebRTC server.

4. Stop the publication, and stop the Wireshark capture.

5. Close Chromium.

The result of these actions is that a DTLSv1.2 connection is established between the client (Chromium) and the server (mediasoup), immediately followed by multiple encrypted "Application Data" packets.

The Wireshark "DTLS debug" file was configured but it is empty. The "TLS Debug" file was also configured and it contains all the relevant info from Wireshark, including things like "ssl_restore_master_key can't find master secret by Client Random" and "Cannot find master secret". I can provide it if it is of any help.

Would this use case expected to be working? Anyone able to help?

test.pcapng
keylog.txt

Philipp Hancke

unread,
Jun 4, 2024, 9:54:27 AMJun 4
to discuss...@googlegroups.com
Did you try verbose logging which triggers dcsctp's built-in logging of packets post(pre) decryption?
After that it is the usual text2pcap galore to extract those packets from the logs and turn them into a pcap.

I found that easier than SSLKEYLOGFILE ;-)

--
This list falls under the WebRTC Code of Conduct - https://webrtc.org/support/code-of-conduct.
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/632999e5-01fd-47a0-bfce-d117d7047685n%40googlegroups.com.

Juan Navarro

unread,
Jun 4, 2024, 1:13:17 PMJun 4
to discuss-webrtc
Hi Philipp,

yes, due to --vmodule='*/webrtc/*=2', this enables VERBOSE1 logging for the SCTP modules, and the text_pcap_packet_observer.cc module does print an Hex dump of each packet.

I tried to use SSLKEYLOGFILE because it seems a pretty common mechanism and directly mentioned in Wireshark docs, and also because what I'm trying to do is analyze the differences between how my software is behaving with Chrome and Firefox.

But, apparently, Chrome is not printing all of the DTLS data that Wireshark expects. Do you think this might be a bug in Chrome?

Anyhow, thanks for the pointer. I'll add some code to my wrapper script in order to extract the hex dumps and convert to pcap... it feels like you have already gone through the need to do that, so I hope you don't mind me asking, do you happen to already have at hand some script that does it?

Kind regards,
Juan

Juan Navarro

unread,
Jun 4, 2024, 4:13:50 PMJun 4
to discuss-webrtc
Hi, I'm adding here some more info in case it is useful for a future reader!

The SCTP packet dump --which Chrome prints on its logs when running with --vmodule='*/webrtc/*=1' (1 or higher)-- are in a format that makes it easy to consume by Wireshark's text2pcap tool. The packet dumps could probably be extracted with some grepping, but alternatively it is possible to just pass the whole logs to this tool, once the appropriate regex is written for it:

text2pcap \
    -i 132 \
    -t '%H:%M:%S.%f' \
    -r '^(?<dir>[IO]) (?<time>\d+:\d+:\d+.\d+) (?<seqno>\d{3,}) (?<data>[ [:xdigit:]]+) #.*$' \
    chrome.log \
    capture.pcapng

This regex matches with the packet dump as produced by webrtc/net/dcsctp/public/text_pcap_packet_observer.cc.
132 is the protocol number of SCTP.
The result is a lot of warnings about spaces in the input data, which can be ignored, and a capture.pcapng file that can be opened and analyzed with Wireshark.

Philipp Hancke

unread,
Jun 5, 2024, 10:15:00 AMJun 5
to discuss...@googlegroups.com

Juan Navarro

unread,
Jun 5, 2024, 12:31:08 PMJun 5
to discuss-webrtc
Woah, thanks for pointing that out! There was 0 chance I would find that comment with regular web searches.
Indeed it seems much simpler to just filter out lines with grep and the keyword that Chrome helpfully adds to the end of each one.

For reference for others, this command worked wonderfully! I'm really using a more complex one (teeing the output simultaneously to screen, to file, and to text2pcap), but this is a good starting point:

/usr/bin/chromium-browser --guest \
    --enable-logging=stderr --log-level=0 --v=0 \
    --vmodule='*/webrtc/*=1' \
     2>&1 | grep -F SCTP_PACKET | text2pcap -D -t %H:%M:%S.%f -i 132 - out.pcapng

The only relevant change here is to use "-i 132" instead of "-u", to generate a ready to inspect SCTP capture (otherwise packets would just be recognized as plain UDP packets which have to be manually forced into SCTP decoding every time)

Thanks!
Regards,
Juan
Reply all
Reply to author
Forward
0 new messages