Fix SRTP double-encryption on send#2
Open
DerGuteMoritz wants to merge 1 commit intosteely-glint:mainfrom
Open
Conversation
It turns out that the SRTP send implementation was redundantly encrypting payloads when using the 4-ary `sendPacket` method. The override for that method in `SRTPProtocolImpl` would encrypt the payload data and then proceed to invoke its parent's implementation. That one in turn would invoke the 5-ary `sendPacket` method which is also overriden in `SRTPProtocolImpl`. That override would encrypt the payload a second time, resulting in garbled data on the receiver's end. Fixed by removing the 4-ary override from `SRTPProtocolImpl`.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
It turns out that the SRTP send implementation was redundantly encrypting payloads when using the 4-ary
sendPacketmethod. The override for that method inSRTPProtocolImplwould encrypt the payload data and then proceed to invoke its parent's implementation. That one in turn would invoke the 5-arysendPacketmethod which is also overriden inSRTPProtocolImpl. That override would encrypt the payload a second time, resulting in garbled data on the receiver's end.Fixed by removing the 4-ary override from
SRTPProtocolImpl.Confirmed to work by testing against a real-world VoIP provider's SRTP implementation. However, I was unable to run the
rtpw-based manual tests which I assume either need to be adjusted or must have been failing before?