Encrypted media data (SRTP) uses so called ‘crypto suites’ similar to the ‘cipher suites’ in HTTPS:
- SIP over TLS: Those suites are negotiated via SDES (RFC 4568). In 2006, Cisco finished their corresponding library libSRTP. SDES was added with Asterisk 1.8 in the year 2010.
- SIP over WebSockets: Those suites are negotiated via DTLS-SRTP (RFC 5764). This was added with Asterisk 11 in the year 2012.
These specifications mandate a crypto suite which is based on AES-128/HMAC-SHA and is offered by Asterisk: AES_CM_128_HMAC_SHA1_80. Today, ten years later, this default crypto suite is still deemed secure. Therefore, attacks concentrate on other parts of the security architecture, like (D)TLS, the implementation itself or the storage of the private key.
AES-256 was added in
- (02/2015) Media5-fone 4.1.3,
- (03/2015) Linphone 3.8,
- (03/2016) Acrobits Groundwire 3.3,
- (05/2016) PJSIP 2.5.
Because those VoIP/SIP clients still offer the mandatory AES-128 based crypto suite, no new interoperability issues arise. Except for Acrobits Groundwire → Settings → Preferences → Security → (SRTP) SDES, which allows the user to disable this crypto suite.
Long story short, the attached patch revolves this interoperability issue by adding support for all crypto suites offered by the underlying libSRTP. The current patch is just about SDES and not DTLS-SRTP. This is because there is no known WebRTC browser to test AES-GCM with. The solution would be to patch OpenSSL, patch an existing WebRTC browser and do the similar with res/res_rtp_asterisk.c.
The patch auto-detects the capabilities of your libSRTP. In many distributions, the pre-build libSRTP package does not come with AES-256 or AES-GCM. Therefore please, build libSRTP yourself, for example in Ubuntu 16.04 LTS
To enable this patch in Asterisk 13:
Words of caution:
- Some clients have spelling mistakes in the crypto-suite names and therefore the connection falls back to AES-128/HMAC-SHA.
- Nokia Belle (Symbian/S60) based mobile phones reject the whole SIP-INVITE with status 500 because the shorter crypto-suite name of AES-GCM. Therefore, no call is established when Asterisk starts the call (egress).
- AES-192 created no-audio calls with all tested implementations. If you still want to offer AES-192 on egress calls, you have to add -DENABLE_SRTP_AES_192 to CFLAGS as well.
- AES-256 requires more processing power but might not add any additional security in your scenario. Please, see this and that for up to date information.
- AES-GCM started in October 2008 but is still rather new because its RFC 7714 was finalized in December 2015. Because there were long discussions about the AEAD-Tag-Size suitable for VoIP application, libSRTP from May 2015 or newer is required. Even then, some implementations are incompatible. I did not do any performance tests with AES-GCM because my server architecture is designed not to create much load and therefore this is of no matter to me. Please, have a tests, whether AES-GCM without its HMAC-SHA helps in your server load.
Long story short, you might be better off sticking to just AES_CM_128_HMAC_SHA1_80 which Asterisk offers already. Therefore on default, all crypto suites offered by the underlying libSRTP are enabled only for ingress. When you have to go for additional suites on egress, please, enable those via CFLAGS as shown above.