search

cisco / libsrtp

Library for SRTP (Secure Realtime Transport Protocol)
Other
1.2k stars 472 forks source link

SRTP packets not seen on wireshark #538

Closed shrutimohankumar closed 3 years ago

shrutimohankumar commented 3 years ago

After the text file is encrypted no srtp packets are seen in wireshark instead it shows UDP. How to be sure that we are sending SRTP packets?

paulej commented 3 years ago

Tell Wireshark to decode the packet as RTP and see if the header looks right. The payload being encrypted will look like random bytes, but the RTP header is in the clear.

shrutimohankumar commented 3 years ago

Not able to see RTP packets as well. Does it happen because we are encrypting a text file. Any idea how to encrypt audio file instead of text?

paulej commented 3 years ago

Did you tell Wireshark to decode the packet as RTP? That's a "Decode as" option where you can do that.

Wireshark has no idea what kind of media is being encrypted, so that's not why you see just UDP vs RTP.

shrutimohankumar commented 3 years ago

Yes I have done that using decode as option just as you mentioned still not able to see rtp packets.

wireshark img

paulej commented 3 years ago

It doesn't look like SRTP. I can't see the header, and "deadbeef" in the middle is a clear hint that did not come from libsrtp.

shrutimohankumar commented 3 years ago

Can you please elaborate on correct way to check RTP packets and what exactly to check as header because I am not able to see any. I have installed libsrtp on both sender and receiver side terminals and I am using loopback IP as seen in screen shot in ubuntu and I am checking packets by opening wireshark on third terminal but all I see is UDP packets. Also used the decode as option just as you mentioned. wireshark img 2

paulej commented 3 years ago

I said the 0xdeadbeef suggested this was not a valid RTP packet, but it might be. The first data octet is 0x80, which hints at RTP. The second is 0x01, which is not (presently) a valid payload type, but still legal. Assuming it's RTP, the sequence number is 0xcf00, which could be valid. The timestamp is 0x00000005, which could be valid. The 0xdeadbeef that follows is what would be the SSRC field. Libsrtp does use that as an SSRC in some of the test code, but it's unusual to see that "in the wild". What follows that does appear to be random junk. It's not very long, though. It might still be valid, but I could not tell since, if it were, it would be encrypted and only the person with the key could authenticate it.

I do not know why Wireshark will not decode that as RTP for you. I really can't help with that.

shrutimohankumar commented 3 years ago

Can you please share screen shot of your wireshark window just for reference and how libsrtp output looks for you when you run client and server using loopback IP?

paulej commented 3 years ago

I don't have it installed at the moment, but it's not significantly different than what you sow here. You should be able to right click on a packet and select "decode as" and select RTP. But if that's not working, I really can't help with that.

shrutimohankumar commented 3 years ago

Even I am able to see deadbeef in the code just as you mentioned and in wireshark as well. Is this sufficient to confirm that the packets are RTP or SRTP?

paulej commented 3 years ago

That doesn't mean it's RTP. However, start at 0x80 and looking at each field as I did does. But what would use 0xdeadbeef? The test code does, but I would hope nothing real would. Anyway, this is probably RTP or SRTP.

pabuhler commented 3 years ago

Closing for now, please reopen if you still have issues with libSRTP

jmorrison876 commented 1 year ago

Hi

I get the below error when running the command

./rtp_decoder -a -t 10 -e 256 -k 55502b4c514136647338355855326a674e534f574e4958432b57592b616b562f32367643566f2f41 * < /home/SRTP.pcap | text2pcap -t "%M:%S." -u 10000,10000 - - > /home/RTP.pcap

Using libsrtp2 2.5.0-pre [0x2050000] security services: confidentiality message authentication setting tag len 10 error: too few digits in key/salt (should be 92 digits, found 80) <<<<<< error Input from: Standard input Output to: Standard output Output format: pcap Generate dummy Ethernet header: Protocol: 0x800 Generate dummy IP header: Protocol: 17 Generate dummy UDP header: Source port: 10000. Dest port: 10000 Read 0 potential packets, wrote 0 packets (24 bytes).

I obtained the key by doing a Copy as a Hex Stream on the below. image

pabuhler commented 1 year ago

You set the key size to be 256 but from that screen shot it should only be 128, ie AES_CM_128_HMAC_SHA1, so change your command to be: ./rtp_decoder -a -t 10 -e 128 -k 55502.........