Panic due to improper handling of use_srtp extension
#649
Comments
|
Thanks for this detailed analysis. Could you submit a PR to fix this issue? |
|
Ran into the same thing, thanks @Deluvi for posting this as I thought it was me Found a resolution for my code without patching the crate: use webrtc::dtls::extension::extension_use_srtp::SrtpProtectionProfile;
...
let mut setting_engine = webrtc::api::setting_engine::SettingEngine::default();
setting_engine.set_srtp_protection_profiles(vec![
SrtpProtectionProfile::Srtp_Aead_Aes_128_Gcm,
SrtpProtectionProfile::Srtp_Aes128_Cm_Hmac_Sha1_80,
]);
// Create the API with the MediaEngine and Interceptors
let api = APIBuilder::new()
.with_setting_engine(setting_engine)
.with_media_engine(media_engine)
.with_interceptor_registry(registry)
.build(); |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello everyone !
For a project, I wanted to integrate OpenAI's Realtime API using the WebRTC method.
However, upon connecting using this webrtc-rs library, I encountered a panic:
Panic in webrtc-srtp-0.14.0/src/key_derivation.rs
After digging, I found out that the panic is due to trying to fit a 32 bytes slice into a 16 bytes AES128 key.
At this point, I decided to debug the issue by patching the library to add debug prints. Here is what I found.
First, the cipher picked:
So AES128, which makes sense that we expected a 16 bytes key. But why did the library generated a 32 bytes key ?
I found out that the key len is calculated in
extract_session_keys_from_dtls. By adding further debug prints, I found out that:Aes256, what?!
After digging a bit more, I found out that this profile can be set through the SRTP protection profile extension:
I found out that this was picked in flight 0:
This correspond to the
use_srtpextension that the server gives if I understood correctly.This list is given to
find_matching_srtp_profile, which pick the first compatible srtp profile. The Aes256 one being the first, it is the one that got picked by the client.We take the key length of the srtp profile (Aes256, 32 bytes), which does not match the key length of the overall cipher (Aes128, 16 bytes), which cause the issue.
By patching the crate and overriding the
dtls_conn.selected_srtpprotection_profile()toSrtp_Aead_Aes_128_Gcm, I managed to successfully communicate with OpenAI backend, so this was indeed a bad handling of theuse_srtpextension by the crate.The text was updated successfully, but these errors were encountered: