Open achaloyan opened 9 years ago
Hi Arsen,
I can try, with your guidance, implement the crypto myself. A brief analysis follows.
All the features should be optional from both client-side and server-side, on compile-time
and run-time. On the other hand, they should be enforcable by configuration. I would
focus on MRCPv2, when finished, securing MRCPv1 (if needed) should be straightforward.
I see three stages of the issue: SIP, TCP/MRCPv2 and RT(C)P; from easiest to hardest.
1. Sofia-SIPS (transport=tls)
Certificate file names and other things hardcoded in Sofia-SIP, location specified
just by directory. I would stick to this and design the features accordingly.
Default certificates/keys location:
conf/agent.pem, conf/cafile.pem (optionally conf/tls_seed.dat).
Common crypto params:
<properties>
<!-- Security level -->
<security>0..off 1..tolerated 2..preferred 3..required</security>
<!-- Certificate and key directory -->
<cert-dir>conf/</cert-dir>
<!-- Private key passphrase -->
<pk-passphrase>XXXX</pk-passphrase>
<!-- SSL or TLS -- according to Sofia -->
<tls-version>0..SSL 1..TLS</tls-version>
<!-- Require valid client certificate or check server cert -->
<tls-verify-peer>0..off 1..on</tls-verify-peer>
<!-- List of allowed peers -->
<x509-subjects>
<subj>CN=nnn/O=mmm/...</subj>
</x509-subjects>
</properties>
GNU build of Sofia detects OpenSSL automatically, on Windows, some files must be added
to its VS project and OpenSSL must be enabled in config.h. Of course, OpenSSL must
be availabe. I suggest let users install it and set up default include and library
paths of Visual C++. Then I suggest to patch the affected Sofia sources so that only
editing config.h would be necessary, i.e. enclose entire content of the added files
in an #ifdef.
New attributes (inheritable from <properties>) of <sip-uac> and <sip-uas>:
<security>
<cert-dir>
<pk-passphrase>
<tls-version>
<tls-verify-peer>
<x509-subjects>
<sip-port> and <sip-transport> may be omitted -- equivalent to security=3.
New attributes for UAS and UAC:
<sips-port>8061</sips-port>
<sips-transport>tls</sips-transport>
New attributes for UAC settings:
<server-sips-port>8061</server-sips-port>
2. TCP/MRCPv2
Detect OpenSSL in GNU build and in Windows build (props and vsprops?).
New attributes (inheritable from <properties>) of <mrcpv2-uac> and <mrcpv2-uas>:
<security>
<cert-dir>
<pk-passphrase>
<tls-version>
<tls-verify-peer>
<x509-subjects>
<mrcp-port> may be omitted -- equivalent to security=3.
New attributes for UAS:
<mrcp-tls-port>1545</mrcp-tls-port>
SDP offer for security=0 (unchanged):
m=application 9 TCP/MRCPv2 1
SDP offer for security=1 [rfc5939]:
m=application 9 TCP/TLS/MRCPv2 1
a=tcap:1 TCP/MRCPv2
a=pcfg:1 t=1
SDP offer for security=2 [rfc5939]:
m=application 9 TCP/MRCPv2 1
a=tcap:1 TCP/TLS/MRCPv2
a=pcfg:1 t=1
SDP offer for security=3:
m=application 9 TCP/TLS/MRCPv2 1
Implement apt_tls_(accept,connect,send,recv) to be used transparently with TLS socket
and incorporate to mrcp_connection.
3. SRTP
Add libsrtp to dependencies.
New attributes (inheritable from <properties>) of <rtp-factory>:
<security>
SDP offer for security=0 (unchanged):
m=audio 4000 RTP/AVP 0 8 96 101
SDP offer for security=1:
rfc5939:
m=audio 4000 RTP/SAVP 0 8 96 101
a=tcap:1 RTP/AVP
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj
a=pcfg:1 t=1
SDP offer for security=2:
rfc5939:
m=audio 4000 RTP/AVP 0 8 96 101
a=tcap:1 RTP/SAVP
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj
a=pcfg:1 t=1 a=1
unofficial, but sometimes used, will also be accepted:
m=audio 4000 RTP/AVP 0 8 96 101
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj
SDP offer for security=3:
m=audio 4000 RTP/SAVP 0 8 96 101
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj
Implement crypto requirement and keying fields to rtp_descriptor and apply SRTP.
Request for SRTP should be rejected if signaling (RTSP or SIP) is not secure, or at
least logged with high severity and accepted for debugging purposes.
Alternatively (later), DTLS/SRTP may be implemented and it should be the preferred
option.
When the time comes, I will create a new branch and start committing to it. Or would
you prefer to do it in my repo and when usable results appear, commit it as a whole?
- Vali
Reported by tomas.valenta@speechtech.cz
on 2014-05-27 18:30:36
Is this enhancement still under active development?
Short answer: no.
We discussed this issue with Vali in great details back in 2015, and made a few steps towards the implementation. However, later on, I was told that Vali passed away, such a great sadness....
Substantial changes are still required in order to completely address this issue. I hope sooner or later the time will come ...
With PCI 4, I'm feeling pressure from my organization for MRCP to be fully encrypted. Is there any work being done on this? Are there recommended workarounds people are using successfully?
Has any progress been made with regards to adding support for SIP TLS/SRTP into UniMRCP?
Originally reported on Google Code with ID 170
Reported by
tomas.valenta@speechtech.cz
on 2014-05-12 14:43:55