Required crypto missing in SDP

[apsaras]

Hello.

I am using latest 6.5 version on Centos 7 with openssl-1.0.2k-16 and OpenSIPs 2.4 as a multi homed Proxy running TLS on public interface and UDP on private.

While testing TLS with ZoIPer Client, client complain that required crypto is missing in SDP. From Client Logs we found that during SRTP setup, wrong cypto size is sent to the TLS end point.

More specifically, the received key size sent is 45 bytes instead of the required 46 (256 bit key + 112 bit salt = 368/8=46) and thus the negotiation fails.

Please find bellow the logs of rtpengnine of such call

Feb 27 18:34:10 esbc rtpengine[3781]: DEBUG: Adding a proxy for control ng stats:127.0.0.1 Feb 27 18:34:10 esbc rtpengine[3781]: INFO: [5SEcn5l4a9k3YMrvKqj3GQ..]: Received command 'offer' from 127.0.0.1:59351 Feb 27 18:34:10 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: Dump for 'offer' from 127.0.0.1:59351: { "sdp": "v=0#015#012o=Zoiper 18149393 0 IN IP4 2.2.2.2#015#012s=Z#015#012c=IN IP4 2.2.2.2#015#012t=0 0#015#012m=audio 51512 RTP/SAVP 9 101 8 18#015#012a=rtpmap:9 G722/8000#015#012a=rtpmap:101 telephone-event/8000#015#012a=fmtp:101 0-16#015#012a=rtpmap:8 PCMA/8000#015#012a=rtpmap:18 G729/8000#015#012a=fmtp:18 annexb=no#015#012a=sendrecv#015#012a=crypto:5 AES_256_CM_HMAC_SHA1_80 inline:C/ZVbnKy4GQ0xzldo88VZMlaMnlm9lVLrfaaB9wMHa2mPsc9wqkvwenUeZHlVQ==#015#012a=crypto:6 AES_256_CM_HMAC_SHA1_32 inline:C/ZVbnKy4GQ0xzldo88VZMlaMnlm9 ... Feb 27 18:34:10 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: ... lVLrfaaB9wMHa2mPsc9wqkvwenUeZHlVQ==#015#012a=crypto:9 AES_CM_256_HMAC_SHA1_80 inline:C/ZVbnKy4GQ0xzldo88VZMlaMnlm9lVLrfaaB9wMHa2mPsc9wqkvwenUeZHlVQ==#015#012a=crypto:10 AES_CM_256_HMAC_SHA1_32 inline:C/ZVbnKy4GQ0xzldo88VZMlaMnlm9lVLrfaaB9wMHa2mPsc9wqkvwenUeZHlVQ==#015#012a=crypto:3 AES_192_CM_HMAC_SHA1_80 inline:C/ZVbnKy4GQ0xzldo88VZMlaMnlm9lVLrfaaB9wMHa2mPsc9wqk=#015#012a=crypto:4 AES_192_CM_HMAC_SHA1_32 inline:C/ZVbnKy4GQ0xzldo88VZMlaMnlm9lVLrfaaB9wMHa2mPsc9wqk=#015#012a=crypto:7 AES_CM_192_HMAC_SHA1_80 inline:C/ZVbnKy4GQ0 ... Feb 27 18:34:10 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: ... xzldo88VZMlaMnlm9lVLrfaaB9wMHa2mPsc9wqk=#015#012a=crypto:8 AES_CM_192_HMAC_SHA1_32 inline:C/ZVbnKy4GQ0xzldo88VZMlaMnlm9lVLrfaaB9wMHa2mPsc9wqk=#015#012a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:C/ZVbnKy4GQ0xzldo88VZMlaMnlm9lVLrfaaB9wM#015#012a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:C/ZVbnKy4GQ0xzldo88VZMlaMnlm9lVLrfaaB9wM#015#012", "ICE": "remove", "direction": [ "external", "internal" ], "flags": [ "trust-address" ], "replace": [ "session-connection", "origin" ], "transport-protocol": "RTP/AVP", "call-id": "5SEcn5l4a9k ... Feb 27 18:34:10 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: ... 3YMrvKqj3GQ..", "received-from": [ "IP4", "2.2.2.2" ], "from-tag": "b7a0fa51", "command": "offer" } Feb 27 18:34:10 esbc rtpengine[3781]: ERR: [5SEcn5l4a9k3YMrvKqj3GQ..]: Failed to parse a=crypto attribute, ignoring: unknown crypto suite Feb 27 18:34:10 esbc rtpengine[3781]: ERR: [5SEcn5l4a9k3YMrvKqj3GQ..]: Failed to parse a=crypto attribute, ignoring: unknown crypto suite Feb 27 18:34:10 esbc rtpengine[3781]: ERR: [5SEcn5l4a9k3YMrvKqj3GQ..]: Failed to parse a=crypto attribute, ignoring: unknown crypto suite Feb 27 18:34:10 esbc rtpengine[3781]: ERR: [5SEcn5l4a9k3YMrvKqj3GQ..]: Failed to parse a=crypto attribute, ignoring: unknown crypto suite Feb 27 18:34:10 esbc rtpengine[3781]: NOTICE: [5SEcn5l4a9k3YMrvKqj3GQ..]: Creating new call Feb 27 18:34:10 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: Default sink codec is G722/8000 Feb 27 18:34:10 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: Creating codec handler for G722/8000 Feb 27 18:34:10 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: Sink supports codec G722/8000 Feb 27 18:34:10 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: Creating codec handler for telephone-event/8000 Feb 27 18:34:10 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: Creating codec handler for PCMA/8000 Feb 27 18:34:10 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: Sink supports codec PCMA/8000 Feb 27 18:34:10 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: Creating codec handler for G729/8000 Feb 27 18:34:10 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: set FILLED flag for stream 2.2.2.2:51512 Feb 27 18:34:10 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: set FILLED flag for stream 2.2.2.2:51513 Feb 27 18:34:10 esbc rtpengine[3781]: INFO: [5SEcn5l4a9k3YMrvKqj3GQ..]: Replying to 'offer' from 127.0.0.1:59351 (elapsed time 0.002490 sec) Feb 27 18:34:10 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: Response dump for 'offer' to 127.0.0.1:59351: { "sdp": "v=0#015#012o=Zoiper 18149393 0 IN IP4 192.168.11.180#015#012s=Z#015#012c=IN IP4 192.168.11.180#015#012t=0 0#015#012m=audio 10000 RTP/AVP 9 101 8 18#015#012a=rtpmap:9 G722/8000#015#012a=rtpmap:101 telephone-event/8000#015#012a=rtpmap:8 PCMA/8000#015#012a=rtpmap:18 G729/8000#015#012a=fmtp:101 0-16#015#012a=fmtp:18 annexb=no#015#012a=sendrecv#015#012a=rtcp:10001#015#012", "result": "ok" } Feb 27 18:34:18 esbc rtpengine[3781]: INFO: [5SEcn5l4a9k3YMrvKqj3GQ..]: Received command 'answer' from 127.0.0.1:51868 Feb 27 18:34:18 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: Dump for 'answer' from 127.0.0.1:51868: { "sdp": "v=0#015#012o=root 212864899 212864899 IN IP4 192.168.1.15#015#012s=Microbase CommServer#015#012c=IN IP4 192.168.1.15#015#012t=0 0#015#012m=audio 10118 RTP/AVP 9 8 101#015#012a=rtpmap:9 G722/8000#015#012a=rtpmap:8 PCMA/8000#015#012a=rtpmap:101 telephone-event/8000#015#012a=fmtp:101 0-16#015#012a=ptime:20#015#012a=sendrecv#015#012", "ICE": "force", "direction": [ "internal", "external" ], "flags": [ "trust-address" ], "replace": [ "origin", "session-connection" ], "transport-protocol": "RTP/SAVP", "call-id": "5SEcn5l4a ... Feb 27 18:34:18 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: ... 9k3YMrvKqj3GQ..", "received-from": [ "IP4", "192.168.1.15" ], "from-tag": "b7a0fa51", "to-tag": "as4cde2347", "command": "answer" } Feb 27 18:34:18 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: Eliminating asymmetric inbound codec G729/8000 Feb 27 18:34:18 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: Default sink codec is G722/8000 Feb 27 18:34:18 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: Eliminating asymmetric outbound codec G729/8000 Feb 27 18:34:18 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: Creating codec handler for G722/8000 Feb 27 18:34:18 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: Sink supports codec G722/8000 Feb 27 18:34:18 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: Creating codec handler for PCMA/8000 Feb 27 18:34:18 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: Sink supports codec PCMA/8000 Feb 27 18:34:18 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: Creating codec handler for telephone-event/8000 Feb 27 18:34:18 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: set FILLED flag for stream 192.168.1.15:10118 Feb 27 18:34:18 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: set FILLED flag for stream 192.168.1.15:10119 Feb 27 18:34:18 esbc rtpengine[3781]: INFO: [5SEcn5l4a9k3YMrvKqj3GQ..]: Replying to 'answer' from 127.0.0.1:51868 (elapsed time 0.001119 sec) Feb 27 18:34:18 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: Response dump for 'answer' to 127.0.0.1:51868: { "sdp": "v=0#015#012o=root 212864899 212864899 IN IP4 1.1.1.1#015#012s=Microbase CommServer#015#012c=IN IP4 1.1.1.1#015#012t=0 0#015#012m=audio 10000 RTP/SAVP 9 8 101#015#012a=rtpmap:9 G722/8000#015#012a=rtpmap:8 PCMA/8000#015#012a=rtpmap:101 telephone-event/8000#015#012a=fmtp:101 0-16#015#012a=sendrecv#015#012a=rtcp:10001#015#012a=crypto:9 AES_CM_256_HMAC_SHA1_80 inline:FHiACl7307mrBo1m+ehfNlaL3IGbbcvVS10PK9hCr7fAkL6k49zludbAM8HA2g#015#012a=ptime:20#015#012a=candidate:LMrEXbGChlG7LZGJ 1 UDP 2130706431 1.1.1.1 10000 ... Feb 27 18:34:18 esbc rtpengine[3781]: DEBUG: [5SEcn5l4a9k3YMrvKqj3GQ..]: ... typ host#015#012a=candidate:LMrEXbGChlG7LZGJ 2 UDP 2130706430 1.1.1.1 10001 typ host#015#012", "result": "ok" }

[rfuchs]

The key size sent is correct, but rtpengine is omitting the padding characters (==) as per RFC. Looks like Zoiper expects them to be there and fails to decode the base64 without them. Add pad-crypto to your options to fix this.

[apsaras]

Thank you rfuchs for quick response. Can you please be more specific on how can I add pad-crypto ?

I will forward your message to Zoiper Support team!

[rfuchs]

Wherever you call rtpengine from, e.g. rtpengine_offer("blah foo") and add it there: rtpengine_offer("blah foo pad-crypto"). In this case you would need it in the answer but you can add it anywhere.

[rfuchs]

The RFC is a bit ambiguous in this regard (https://tools.ietf.org/html/rfc4568#section-6.1 says When base64 decoding the key and salt, padding characters (i.e., one or two "=" at the end of the base64-encoded data) are discarded (see [RFC3548] for details).) and both versions (with padding and without padding) can be found in the wild and so both should be accepted.

[apsaras]

It works just fine!

Thank you again for your support

[SipSeb]

I was just confronted with this Zoiper Bug by a customer. Before enabling this option, can someone tell me if enabling it broke something with devices other than Zoiper?

[apsaras]

Hello @SipSeb

Based on my experience, no, it doesn't brake anything else.

[amessina]

@SipSeb I found that Bria for Android also needs pad-crypto.