When I enable the sslprovider and start a tcpdump on the server-side in order to decode TLSv1.3 traffic, only the CLIENT_HANDSHAKE_TRAFFIC_SECRET and SERVER_HANDSHAKE_TRAFFIC_SECRET ‘keys’ are stored in the packet capture file, but the CLIENT_TRAFFIC_SECRET and SERVER_TRAFFIC_SECRET ‘keys’ are missing. This prevents me to decode the application data in the packet capture:
# tmsh modify sys db tcpdump.sslprovider value enable<br># tcpdump -i <em><server-side-VLAN></em> -s0 -f5 ssl:v -vvv -w /var/tmp/output.cap <br><br><em><Generate traffic></em><br><br># tshark -r /var/tmp/output.cap -Y "f5ethtrailer.tls.keylog" -T fields -e f5ethtrailer.tls.keylog
On the client-side, this works as expected.
Is this a bug (tested with TMOS 17.5.1)? Am I doing something wrong?
I mean CLIENT_TRAFFIC_SECRET_0 and SERVER_TRAFFIC_SECRET_0 are missing.
Hi Momahdy,
Thanks for pointing me to this KB article. I am aware of the ‘iRule-way’ to get the PMS data.
The observed sslprovider behaviour (missing CLIENT_TRAFFIC_SECRET_0 and SERVER_TRAFFIC_SECRET_0 data) sort of defies the purpose of it, doesn’t it?
Should I report a bug with F5 TAC, or is this a known issue already?
I always use this script to grab and reinject the secrets: https://github.com/JuergenMang/f5-tls-decrypt
You can check it to see if the issue is within tshark.
Hi @Frank_ten_Wolde
Got what you mean, I don’t see published IDs on this one, If you may try couple of items and reach to TAC if the same behavior continues,
- Make sure to include the p option,
tcpdump -i <server-side-VLAN>:nnnp -s0 -f5 ssl:v -vvv -w /var/tmp/output.cap