Ask Your Question

gRPC traffic dissector with TLSv1.3

asked 2023-07-04 14:26:29 +0000

Stew4690 gravatar image

updated 2023-07-04 15:18:30 +0000

Hey, I am trying to read some gRPC traffic that has been encrypted over TLSv1.3, but so far I am not having any success. I am using a client and a server written in C++, and exporting the tls session key to a txt file which has the following format:

I put this file in the field (Pre)-Master-Secret log filename of the TLS protocol settings. At that point I expect to be able to read the traffic but that is not the case. Is the format of key correct and/or am I misunderstanding something ? Did someone succeed in doing this ?

TLS logs:
Those suspicious line:
- tls13_load_secret Cannot find SERVER_TRAFFIC_SECRET_0, decryption impossible
- tls13_load_secret Cannot find CLIENT_HANDSHAKE_TRAFFIC_SECRET, decryption impossible

But I can't make any sense of this, since those variable are in the file.

Thanks ! I can put sample files if needed.

edit retag flag offensive close merge delete


TLS - Preference Settings - have you tried enabling the debug file and checking the output for errors?

Chuckc gravatar imageChuckc ( 2023-07-04 14:54:20 +0000 )edit

Just did that and updated post but I don't really understand why it doesn't find the variable.

Stew4690 gravatar imageStew4690 ( 2023-07-04 15:19:22 +0000 )edit

There is a tls13-debug.txt attached to issue 12779: Add TLS 1.3 support

Does your log have the trying to use SSL keylog in "filename" entry?

Chuckc gravatar imageChuckc ( 2023-07-04 15:42:27 +0000 )edit

It has trying to use TLS keylog in "path to filename"

Stew4690 gravatar imageStew4690 ( 2023-07-04 15:52:45 +0000 )edit

Can you share the debug log or the capture and key log file?
(Place them on a public file share and add the link in the question above)

Chuckc gravatar imageChuckc ( 2023-07-05 00:24:11 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2023-07-05 09:58:22 +0000

Stew4690 gravatar image

Okay, found the answer, the issue came from the end of line format. The file was on CRLF and not LF so wireshark was reading the whole file as a single line. My bad... Thanks for your help !

edit flag offensive delete link more


It would help if you add the output of wireshark -v or Help->About Wireshark:Wireshark to the question.
The example I gave in the issues was from an older version of Wireshark so ssl vs tls.
There was a somewhat related issue with dfilters that might also need to be applied to the key log files.
18082: "dfilter" file on Windows adds carriage returns, and requires line feeds

Chuckc gravatar imageChuckc ( 2023-07-05 12:40:18 +0000 )edit

Are you still open to sharing the original files and Wireshark version info?
I modified the openssl_keylog.txt in issue 12779 to have CRLF EOL and the decode works fine in Wireshark 4.0.6.

Chuckc gravatar imageChuckc ( 2023-07-05 14:39:54 +0000 )edit

My bad

No, our bad. Given that text files may be written on Windows and read in a UN*X Wireshark, or written on a UN*X system and read in a Windows Wireshark, we need to be able to handle text files with LF-only line endings in the Windows version of Wireshark and handle text files with CR-LF line endings in the UN*X version(s) of Wireshark.

Please file an issue on this on the Wireshark issues list.

Guy Harris gravatar imageGuy Harris ( 2023-07-05 19:14:41 +0000 )edit

I will share the files when I get my other pc back. Also the issue might come from how the log file is created in C++, it might not be directly related to LF/CRLF, I will do more test when I have some time.

Stew4690 gravatar imageStew4690 ( 2023-07-06 06:50:17 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools


Asked: 2023-07-04 14:26:29 +0000

Seen: 386 times

Last updated: Jul 04 '23