- Sentinel 100
- Sentinel 400
- Mediatrix S7 and S7 LP Series
- Mediatrix G7 Series
- Mediatrix C7 Series
- Mediatrix 4100 Series
- Mediatrix 3000 Series
- Mediatrix 4400 Series
- Mediatrix LP Series
This document describes the steps required to configure a Mediatrix unit loaded with the DGW firmware for secure SIP signalling and secure media (SRTP) operation.
This is not a complete key-exchange, TLS or general security tutorial. For more information on these topics, please see the links section.
In this scenario, the endpoints used are a Mediatrix 41XX and a Mediatrix 4402 BRI Gateway units. Both Mediatrix units must be loaded with DGW. We will use the freely available openSIPS ( http://www.opensips.org ) as the SIP proxy and configure it for TLS operation.
Using two Mediatrix gateways connected back-to-back using a SIP trunk would be sufficient to demonstrate the use of the new security features. However, we prefer to demonstrate the configuration of the units and test scenarios in a more real-world environment by using a separate TLS-enabled SIP proxy. For this purpose, we have chosen openSIPS as it is free and easy to configure for basic use.
For more information on setting up openSIPS, please refer to the openSIPS installation
Note If already completed, skip this section.
If already completed, skip this section.
Please note that at the moment of writing this, openSIPS is configured by default to keep the TLS links up for a period of 2 minutes. We have made a small code modification that allows the links to stay up for 120 minutes. See the annex for more information on how to procede.
The Mediatrix unit uses digital certificates, which are a collection of data used to verify the identity of individuals, computers, and other entities on a network.
Although certificates are factory-installed new ones can also be added. Since certificates have a validity period (start date and expiry date), the use of NTP (Network Time Protocol) is mandatory when using the security features.
The Mediatrix unit uses two types of certificates:
To enable a TLS connection on Mediatrix units, no CA certificate needs to be installed if the respective parameters for each secure service (e.g. SIP, Conf, Cwmp, etc) has the NoValidation value. If the value is different than NoValidation, then at least one CA certificate needs to be installed. This certificate must be uploaded to the Mediatrix units. The Mediatrix unit then checks the server identity by validating the host name used to contact it against the information found in the server's certificate. If the validation fails, the Mediatrix unit refuses the secure connection. For the SIP over TLS service, we have four (4) levels of validation: HostName, trustedCertificate, DNSSRV, and NoValidation (for a complete description of the validation levels, refer to the Help of the DGW Web interface under SIP/Interop). The way that the remote peer is evaluated for secure connection differs for each level. Remember that the unit must be correctly configured with an SNTP server because the TLS server certificate is also validated in terms of time (certificate validation/expiration date, etc.).
For example in a setup for two Mediatrix gateways with no SIP proxy in the middle. At least one of the units will require a Host certificate. If only one unit has a Host certificate, the calls will be allowed in only one direction (Unit 1 calls Unit 2). For bi-directional calls, both Mediatrix units would require a Host certificate. By default it is not possible to upload a Host certificate without first clicking on Activate unsecure certificate transfer. This is because the certificate upload will be done in clear text, which means the private key will be susceptible to interception.
Certificates are used to secure the following connections:
At the level at which we are working, establishing a TLS connection may seems fairly straightforward. However in practice, at a lower level, there are a lot of additional complications to consider to insure a protection against various possible attacks.
Here is an example of an overall exchange in order to build a TLS link and bring it "up"
When obtaining the server certificates during the early negotiation, the following information will be checked by the client:
If any of these steps fail, the TLS link will not go "up". For those familiar with HTTPS, this is essentially the same procedure but using a SIP server/proxy instead of a HTTPS server.
CA certificate files usually have a .crt extension, using format X.509.
For gateway-specific settings, use the Gateway Specific sections.
For gateway-specific settings, use the Gateway Specific sections.
The Mediatrix unit does not support a mix of both TLS and non-TLS links. Once TLS is enabled, it is enabled for all configured SIP gateways
Syslog message: USER.INFO: SipEp:
1400-SIP Endpoint: 303-TLS connection with remote host 10.5.128.14:5063 is now
ready to be used for SIP gateway default.
USER.INFO: SipEp: 1400-SIP Endpoint: 310-Server 10.5.128.14:5063 is now
reachable for SIP gateway default.
Enabling SDES instead of Mickey will make the INVITE slightly different. SDES parameters will be added to the SDP Media Attributes instead of the Session Attributes.
The Mediatrix unit supports AES with 128 bits.
The choice "NULL" will not encrypt the RTP. This option should only be selected for debugging purposes.
T.38 packerts will never be encrypted. The setting Allow Unsecure T.38 with Secure RTP will make possible to use T.38, otherwise it will be rejected.
The field specifies the binding between an IP address, a port, a protocol, and a RSA decryption key. Enter the IP address of the server, the SIP port, and the path to the file containing the server private key. Several such bindings may be specified by separating them with a semi-colon ";".
TLS sessions using Diffie-Hellman based ciphers (DHE, ECDH, ECDHE) cannot be decrypted by Wireshark.
TLS is enabled on one of the Mediatrix gateways and not on the second gateway.
Issue: The REGISTER requests from the second gateway are not being answered.
Reason: The proxy is expecting the SIP message to be SSL encapsulated.
Procedures to solve the issue: Restart the Wireshark capture and enable TLS on the second gateway. Restart the required services.
Some servers/proxies will require Interop variables to be enabled.
For example, the default openSIPS installation requires adding the SIP transport field in the registration and contact headers.
This document explains why it is highly recommended to choose only one single key management protocol.
In the following example, SDES is configured on endpoint 1 (192.168.120.30) and Mikey on endpoint 2 (192.168.120.12)
The gateway 192.168.120.12 returns a SIP 415 Unsupported Media error because it is not configured to manage SDES.
The following Syslog message should also be seen:
syslog: SdpTools [D3A2] Received the wrong key management protocol. Secure stream disabled.
Copyright © 2018 Media5 Corporation.
This document contains information that is proprietary to Media5 Corporation.
Media5 Corporation reserves all rights to this document as well as to the Intellectual Property of the document and the technology and know-how that it includes and represents.
This publication cannot be reproduced, neither in whole nor in part, in any form whatsoever, without written prior approval by Media5 Corporation.
Media5 Corporation reserves the right to revise this publication and make changes at any time and without the obligation to notify any person and/or entity of such revisions and/or changes.