search

cisco / libsrtp

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

call srtp_unprotect return srtp_err_status_auth_fail when rtp seqnum around 655xx but roll back to small value(like 20,30) the api return is ok. #567

Closed ricelmm closed 1 year ago

ricelmm commented 2 years ago

Hi dear all i meet one issue whic make me have confused for few days. i step up one webrtc media server (like licode, mediasoup) and use chrome to publish stream. The server is built by openssl 1.0.2 and libsrtp 2.3.0. And i found one issue happened at 10% lost network which simulate at PC using clumsy2.0 image when the rtp seqnum at around 655xx and the rtp packet is nack from chrome. i found call srtp_unprotect return srtp_err_status_auth_fail and when the seqnum roll back to small number this API return is ok. And i enable the libsrtp debug log and i found that log like this: srtp: function srtp_unprotect srtp: estimated u_packet index: 000000000000ffb2 srtp: estimated u_packet index: 000000000000ffb2 aes icm ossl: setting iv: 000000008ee3dd6b00000000ffb20000 aes icm ossl: set_counter: 195c023f26efb0a4b2b37224433a0000 hmac sha-1 openssl: input: 9066ffb2d3d287058ee3dd6bbede0001e2016044dba62d99e8dc4f2abbbd1e92 hmac sha-1 openssl: output: ab66673e9e1b429a6830 srtp: computed auth tag: ab66673e9e1b429a6830 srtp: packet auth tag: cdb78cfc764fe807f4ab hmac sha-1 openssl: input: 9066ffb2d3d287058ee3dd6bbede0001e2016044dba62d99e8dc4f2abbbd1e92 hmac sha-1 openssl: output: ab66673e9e1b429a6830 srtp: computed auth tag: ab66673e9e1b429a6830 srtp: packet auth tag: cdb78cfc764fe807f4ab

and input rtp_unprotect the packet(hex content) is the same with the packet is captured from wireshark. And we use srtp_profile_aes128_cm_sha1_80, and when we upgrade openssl 1.1.1 and libsrtp 2.3.0 this issue still exist.

so why return fail when rtp seqnum is 655xx and rtp packet is discorder while roll back is ok?

ricelmm commented 2 years ago

hello.... anybody can help me?

pabuhler commented 2 years ago

@ricelmm I tried to follow the question but it was not 100% clear. Are you able to make a simple test case the reproduces the behavior? It would make it much easy to see what you are experiencing and to understand what is expected.

If I understand correctly what you are saying it is that when the seq number wraps and the ROC increase in side libsrtp then out of order packets will fail even though they are within the replay window, does this sound correct ? If so then testing it should be relatively easy and I can try to find some time to verify it, but like I said I was not 100% sure what you are experiencing so If you could make a test it would be better.

ricelmm commented 2 years ago

sure. how to test? i think that how about this case: 65534, 0, 2, 1, 65535. for this case, i think the ROC is like this: a, a+1, a+1, a+1, a+1, a

ricelmm commented 2 years ago

@ricelmm I tried to follow the question but it was not 100% clear. Are you able to make a simple test case the reproduces the behavior? It would make it much easy to see what you are experiencing and to understand what is expected.

If I understand correctly what you are saying it is that when the seq number wraps and the ROC increase in side libsrtp then out of order packets will fail even though they are within the replay window, does this sound correct ? If so then testing it should be relatively easy and I can try to find some time to verify it, but like I said I was not 100% sure what you are experiencing so If you could make a test it would be better.

================================================ sure. how to test? i think that how about this case: 65534, 0, 2, 1, 65535. for this case, i think the ROC is like this: a, a+1, a+1, a+1, a+1, a

ricelmm commented 2 years ago

hello....any update?

pabuhler commented 2 years ago

@ricelmm the test case in #583 tries to reproduce this issue but it pass. It also passes if I run the test in 2.3.0 . Could you try to confirm that it is testing what you think to be an issue? If possible you can try to change the test to fail. If you have a small capture with packets and a key then I can decrypt and verify that they are correct and that the sender is not using the wrong ROC. Other wise I am not sure what we can do to help.

ricelmm commented 2 years ago

@pabuhler ohh okk....maybe i need some time to do what u say later. thank you.