Summary:	ASTERISK-26190: [patch] SRTP: Enable AES-256 and AES-GCM.
Reporter:	Alexander Traud (traud)	Labels:	patch pjsip webrtc
Date Opened:	2016-07-13 06:44:36	Date Closed:	2020-05-22 05:36:50
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Resources/res_srtp
Versions:	13.0.0	Frequency of Occurrence
Related Issues:	causes ASTERISK-26253 sdp_srtp: libsrtp now a required dependency, shouldn't be contains ASTERISK-22832 Support AES-GCM mode in SRTP cannot be resolved before merging of ASTERISK-25289 Build System does not respect CFLAGS and CXXFLAGS when building menuselect is related to ASTERISK-29625 srtp cryptos accepted if not enabled
Environment:		Attachments:	( 0) srtp_aead_and_big_aes.patch
Description:	Encrypted media (sRTP) uses so called ‘crypto suites’ similar to the ‘cipher suites’ in HTTPs: - SDES-sRTP: Those suites are negotiated via SDES ([RFC 4568|https://tools.ietf.org/html/rfc4568#section-6.2]). In 2006, Cisco finished their corresponding library libSRTP. This was [added|https://issues.asterisk.org/jira/browse/ASTERISK-5267] with Asterisk 1.8 in the year 2010. - DTLS-sRTP: Those suites are negotiated via DTLS ([RFC 5764|https://tools.ietf.org/html/rfc5764#section-4.1.2]). This was [added|https://reviewboard.asterisk.org/r/2113] with Asterisk 11 in the year 2012. Those 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. Nevertheless, additional crypto suites were added to [SDES|https://www.iana.org/assignments/sdp-security-descriptions] and [DTLS|https://www.iana.org/assignments/srtp-protection]. Since May 2010, libSRTP offers AES-256 ([RFC 6188|https://tools.ietf.org/html/rfc6188]). Since May 2015, libSRTP [offers|https://github.com/cisco/libsrtp/commit/d63d4f03c69dfd339834a1ff1511b53a23902b05] AES-GCM ([RFC 7714|https://tools.ietf.org/html/rfc7714]). AES-256 was added in - (11/2008) *innovaphone V7*, - (05/2010) *Ascom i62*, - (02/2015) Media5-fone 4.1.3, - (03/2015) Linphone 3.8, - (08/2015) Avaya 96x1 SIP, Avaya H1xx SIP, Avaya J100 SIP, - (03/2016) *Acrobits Groundwire 3.3*, - (05/2016) PJSIP 2.5, - (08/2018) LANCOM Systems LCOS 10.12. AES-GCM was added in - (07/2018) Cisco IP Phones with Multiplatform Firmware 11.2 (SKU must contain 3PCC) Because VoIP/SIP clients have to offer the mandatory AES-128 based crypto suite, no new interoperability issues arise. However, four clients allow to be configured for only AES-256 or -GCM by the user: - Acrobits Groundwire → Settings → Preferences → Security → (SRTP) SDES - Ascom i62 → WinPDM - Cisco → Web interface → Admin → VoIP → Ext - innovaphone → Web interface → Phone (→ General) → SRTP Cipher Long story short, the attached patch revolves those interoperability issues by supporting all crypto suites offered by the underlying libSRTP. The current patch is just about SDES-sRTP 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|https://github.com/openssl/openssl/pull/521], 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: {noformat}sudo apt install libssl-dev wget github.com/cisco/libsrtp/archive/v2.tar.gz tar -zxf v2.tar.gz cd ./libsrtp-* ./configure --disable-debug --disable-stdout --enable-openssl make shared_library sudo make install{noformat} To enable this patch in Asterisk 13:{noformat}patch -p0 <./srtp_aead_and_big_aes.patch CFLAGS='-DENABLE_SRTP_AES_256 -DENABLE_SRTP_AES_GCM' ./configure make sudo make install{noformat} From my [collection of user agents|https://www.traud.de/voip/], the following failed to establish a call when Asterisk offers AES-256 (egress): - Akuvox - Auerswald - BeeHD - Escene (crypto tag has no index) - Fanvil (crypto line empty) - Jami, formerly Ring - Nokia Series 40 - Poly OBi Edition, formerly Obihai - PortSIP - RTX (SIP status 488) - Zoiper (SIP status: 415) If not noted otherwise, those SDES-sRTP implementations go for the first crypto-tag index, ignoring the crypto-suite name, resulting in a call with one-way audio. From my [collection of user agents|https://www.traud.de/voip/], the following failed to establish a call when Asterisk offers AES-GCM (egress): - AVM FRITZ!Box (SIP status 488) - innovaphone (SDP broken completely) - Nokia Symbian/S60 (SIP status 500) - plus the ones above which failed on AES-256 More words of caution: - Older user-agents have spelling mistakes in the crypto-suite names and therefore the connection falls back to AES-128. - AES-192 [created|https://github.com/cisco/libsrtp/pull/170] 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. - AES-256 requires more processing power but might not add any additional security in [your scenario|https://www.traud.de/trust-anchors/seclevel_4.htm]. Please, see [this|https://security.stackexchange.com/q/61361] and [that|https://security.stackexchange.com/q/14068] for up to date information. - AES-GCM started in October 2008 but is still rather new because its [RFC 7714|https://tools.ietf.org/html/rfc7714] was finalized in December 2015. Because there were [long|http://fm4.orf.at/stories/1737330/] [discussions|https://www.ietf.org/mail-archive/web/cfrg/current/msg07099.html] about the AEAD tag size suitable for VoIP applications, libSRTP from May 2015 or newer is required. Even then, some implementations are [incompatible|https://github.com/cisco/libsrtp/pull/184]. 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|https://www.ietf.org/mail-archive/web/cfrg/current/msg02980.html] in your server load. Therefore, in this patch for Asterisk, all crypto suites offered by the underlying libSRTP are enabled only for ingress. Egress is not changed on default = if you do not configure with CFLAGS. If you have to go for additional suites on egress, please, enable those via CFLAGS as shown above. Even then, AES-256 and AES-GCM are offered in low priority to avoid as many interoperability issues as possible. Therefore, if your remote party does not pick the strongest crypto suite, you also have to change the [offered order …|https://community.asterisk.org/t/256/77157/23]
Comments:	By: Asterisk Team (asteriskteam) 2018-08-29 04:47:29.512-0500 This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable. By: Asterisk Team (asteriskteam) 2018-08-29 06:12:44.642-0500 This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable. By: Asterisk Team (asteriskteam) 2019-01-30 12:33:53.755-0600 This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable. By: Asterisk Team (asteriskteam) 2020-05-22 05:34:59.392-0500 This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable. By: Asterisk Team (asteriskteam) 2020-05-22 05:35:45.052-0500 This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable.