VoIP Security with Asterisk

By Thomas Wygonik

 

Configuring an enterprise voice over IP (VoIP) environment can be extremely complicated, and adding security on top of VoIP creates another layer of complexity. With paid solutions such as Cisco Unified Communications Manager (CUCM), VoIP security somewhat easy to configure. With free software, like the Asterisk private branch exchange (PBX), setting up security is a complex task. Documentation for Asterisk VoIP security is very poor. Therefore, this will be a guide to setting up a basic secure VoIP environment. Before diving into securing VoIP, key terms and ideas must be explained, and a normal, unsecure VoIP setup must be configured.
When making a phone call over the IP network, there are two types of protocols in play: signaling and media transport. To exchange metadata information and connect the call, a signaling protocol is used. The information that is exchanged includes the phone numbers involved, IP addresses of the servers that are involved, and what codecs are available. Signaling protocols identify the state of the connection between VoIP devices. The big three signaling protocols that are in use today are H.323, skinny call control protocol (SCCP, or skinny), and the session initiation protocol (SIP). H.323 is on the way out, and skinny is starting to age as well, while SIP is the protocol that greenfield deployments will most likely use for signaling. SIP is the protocol that will be used in this setup.

Above is the basic SIP call flow. This process happens each time there is a successful call between two VoIP phones. It can change based on the number of hops between each phone, and if the call is successful or not. After exchanging this information, an audio stream is established between the phones. This is the media transport protocol. The main media transport protocol used is the Real-time Transport Protocol (RTP). Later in this setup secure RTP (SRTP) will be used.

Prerequisites

• Two CentOS Servers running Asterisk
• Zoiper softphones installed on two client machines

Figure 2: Topology

Unencrypted Setup

This setup consists of two CentOS servers running Asterisk, registered and connected to each other, with one or more phones connected to each server. For phones, use the Zoiper softphone. This is by no means the best softphone on the market, but it has the functionality necessary for demonstration purposes. Before adding encryption, you must have connectivity across the topology, so one phone can call the other on a different server. Asterisk comes with two different SIP modules, a standard SIP module and the PJSIP module. PJSIP seems to be more powerful, but use the standard SIP module for this setup. The two configuration files that will be dealt with in setup are sip.conf and extensions.conf. sip.conf has the configuration for the SIP channel module, while extensions.conf contains the dialplan for the PBX. Below is the sip.conf file the VoIP setup without TLS.

 

[general] register => rochester:welcome@192.168.49.137/buffalo   [buffalo] type=peer secret=welcome context=buffalo_incoming host=dynamic disallow=all allow=ulaw   [1001] type=peer host=dynamic disallow=all allow=ulaw context=phones dtmfmode=rfc2833 secret=1234

 

When connecting between servers, you need the register line under the general section. Registration requires the host line under the buffalo section to be dynamic, otherwise registration fails. The type for the buffalo section needs to be peer because of the inter-server connection. Context defines the context the section will fall under in the dialplan. Disallow=all means all codecs are disallowed, which is then solved by allowing ulaw the line below.  The secret=1234 under the 1001 sections is the password that should be typed in the Zoiper softphone.

In addition to the sip.conf file, the file extensions.conf also must be included. Extensions.conf contains the dialplan, which establishes the sequence of digits that can be dialed, and what happens when a set of digits are dialed.

[globals]   [general] autofallthrough=yes   [default]   [incoming_calls]   [phones] include => internal include => remote   [internal] exten => _1XXX,1,NoOp() same => n,Dial(SIP/${EXTEN},30) same => n,Playback(the-party-you-are-calling&is-curntly-unavail) same => n,Hangup()   [remote] exten => _2XXX,1,NoOp() same => n,Dial(SIP/buffalo/${EXTEN}) same => n,Hangup()   [buffalo_incoming] include => internal

 

This dialplan says that phones with the extension 1XXX can be contacted locally, while extensions 2XXX will be remote, through the buffalo SIP trunk.

Figure 3: Softphone configuration

 

After enabling both the dialplan and sip configuration files (dialplan reload, sip reload), you can now register the phones to the servers. The following settings in Zoiper will allow the phones to register to their respective servers and call each other.

With everything setup, calling should now work between the phones. In the Wireshark traces, you can see all the details of both the call setup and the RTP stream. The RTP can then be reconstructed and played back.

Figure 4: Unencrypted SIP and RTP Trace

Figure 5: Unencrypted SIP call flow

Figure 6: RTP Stream playback

Certificates

Before modifying the configuration files for encryption, you need to create a new certificate authority (CA) and issue certificates. Certificates must be issued to both to the asterisk servers and to any client devices that will be secured with TLS. SRTP requires TLS and certificates as well. Certificates can be issued from one of the Asterisk servers, from an enterprise certificate authority, or from a trusted intermediate or root certificate authority such as Verisign. Issuing certificates from an enterprise CA can be time consuming. For our purposes, use the built-in Asterisk script to issue the needed certificates. Asterisk includes in its download a script to issue certificates for TLS. The script, ast_tls_cert is in the asterisk source directory, then the subdirectory contrib/scripts/.

Figure 7: Certificate script location

A few certificates were required for SIP TLS. Each Asterisk server, Buffalo and Rochester, requires a server certificate and every client device requires a client certificate. Rochester was made the certificate authority and issued a server certificate using the following command:

./ast_tls_cert -d /etc/asterisk/keys -C 192.168.49.138 -o Rochester

The arguments for this script when creating the Certificate Authority

• -C hostname or IP address
• -O organizational name
• -d output directory of keys
• -o filename for the certificate

You can customize fields within the certificate by adding different flags, like the organizational name field. This was not set in testing, but in a real environment this argument should be set. Create a strong password to protect the CA’s private key. For the canonical name (CN), use either the server’s IP address or domain name. In this case, IP addresses were used. All relevant files were stored in the created directory /etc/asterisk/keys, but best practice would be to store the CA private key and certificate in a different location from the certificate issued to the Rochester box. Using the same script, a certificate was issued to the Buffalo server using the following command:

./ast_tls_cert -d certs -C 192.168.49.137 -o Buffalo -c /etc/asterisk/keys/ca.crt -k /etc/asterisk/keys/ca.key

The script will prompt you to enter the password to unlock the private key file.

New arguments used when issuing a certificate to a server:

• -c path to ca certificate
• -k path to ca private key

 

Move these files securely to the other server using SCP or SFTP. Client certificates must be issued for each client device in the topology. These certificates require a different command from the ast_tls_cert script, adding a flag -m client to specify that the device is a client. If this option is not added, the client’s will fail to negotiate TLS properly. Once again, use the IP or domain name of the client device for the CN field.

./ast_tls_cert -m client -c /etc/asterisk/keys/ca.crt -k /etc/asterisk/keys/ca.key -C 192.168.49.136 -d /etc/asterisk/keys -o 2001

 

New argument when issuing client certificates:

• -m client or server certificate

 

After being generated, two files need to be transferred to the client: the certificate that was generated for that client (2001.crt) and the CA certificate (ca.crt). In our environment, the CA certificate is necessary, because it is not a trusted root CA. By the end of issuing these certificates, the following devices should have the files listed:

Device	Directory	Files
Server Rochester	/etc/asterisk/keys	ca.crt ca.key ca.cfg rochester.crt rochester.key
Server Buffalo	/etc/asterisk/keys	ca.crt buffalo.crt
Softphone 1001	Desktop	ca.crt, 2001.crt
Softphone 2001	Desktop	ca.crt, 2001.crt

 Enabling TLS

Before enabling TLS in this setup, it is important to note that you must first have both servers registered to one another using the unencrypted configuration. If you do not register and configure the servers successfully unencrypted, the TLS setup will not work properly. This seems to be a quirk of Asterisk. Enabling TLS requires adding only a few lines in each server’s sip.conf file.

[general] ;register => rochester:welcome@192.168.49.137/buffalo   ; tls setup tlsenable=yes tlsbindaddr=192.168.49.138:5061 tlscertfile=/etc/asterisk/keys/rochester.pem tlscafile=/etc/asterisk/keys/ca.crt tlscipher=ALL tlsclientmethod=tlsv1   [buffalo] type=peer secret=welcome context=buffalo_incoming host=192.168.49.137 disallow=all allow=ulaw transport=tls   [1001] type=peer host=dynamic disallow=all allow=ulaw context=phones dtmfmode=rfc2833 secret=1234 transport=tls

 

Each server is configured to use their respective certificates and the CA certificate under TLS setup. In addition, the cipher and client TLS method is specified. One line is added to both the server peer and client configuration to enable TLS, transport=tls. Note that in the server peer section the host must be set to the IP address of the other server, otherwise TLS will fail to negotiate properly. Another thing to note is the commenting out of the registration line in the general section of the configuration. While the servers must register to one another first unencrypted, attempting to register with TLS will cause failure. Configuration on the Zoiper softphone can be a somewhat difficult. Below are the fields necessary to get TLS to work properly. Note that the .crt files need to be renamed with the .pem file extension

Figure 8: Zoiper Security Settings

Figure 9: Zoiper TLS encryption settings

Unchecking TLS verification is necessary in our setup, because our softphones do not inherently trust the certificate authority, and cannot verify the certificate. This would not be necessary if you are using an enterprise certificate authority.

Enabling SRTP

Secure RTP (SRTP) requires the use of TLS to negotiate the keys used for encryption. TLS encrypts the sip messages which contain the information to encrypt the transport media. This setup uses Session Description Protocol Security Descriptions (SDES) attached to a SIP message for key negotiation. If SIP was not TLS encrypted, one could intercept the negotiation in transit and listen in on calls. To add SRTP to this setup, both the sip.conf file and the dialplan extensions.conf must be modified. In sip.conf it is as simple as adding one line to your softphone extension configuration; encryption=yes.

[general] ;register => rochester:welcome@192.168.49.137/buffalo   ; tls setup tlsenable=yes tlsbindaddr=192.168.49.138:5061 tlscertfile=/etc/asterisk/keys/rochester.pem tlscafile=/etc/asterisk/keys/ca.crt tlscipher=ALL tlsclientmethod=tlsv1   [buffalo] type=peer secret=welcome context=buffalo_incoming host=192.168.49.137 disallow=all allow=ulaw transport=tls   [1001] type=peer host=dynamic disallow=all allow=ulaw context=phones dtmfmode=rfc2833 secret=1234 transport=tls encryption=yes

 

You also must add two lines to each context in the dialplan. The added configuration lines in the dialplan specify that when connecting the extension should use SRTP.

[globals]   [general] autofallthrough=yes   [default]   [incoming_calls]   [phones] include => internal include => remote   [internal] exten => _1XXX,1,Set(CHANNEL(secure_bridge_signaling)=1) same => n,Set(CHANNEL(secure_bridge_media)=1) same => n,Dial(SIP/${EXTEN},30) same => n,Playback(the-party-you-are-calling&is-curntly-unavail) same => n,Hangup()   [remote] exten => _2XXX,1,Set(CHANNEL(secure_bridge_signaling)=1) same => n,Set(CHANNEL(secure_bridge_signaling)=1) same => n,Dial(SIP/buffalo/${EXTEN}) same => n,Hangup()   [buffalo_incoming] include => internal

Then change one setting in the Zoiper softphone, rport media TLS with SDES SRTP. Zoiper indicates that the call is now encrypted end to end with the green padlock. While Wireshark can still see the RTP traffic being sent between clients, it is now encrypted. The RTP stream can be played back, but now all that can be heard is static.

Figure 12: SRTP stream playback

The softphone attempts to make the call with SRTP encryption. In this setup, if both ends are not using SRTP, the call will fail. Interestingly, the Asterisk logs show that the softphones first attempt to use AES 256 encryption, AES 192, and eventually settle on AES 128.

Figure 13: SRTP crypto negotiation

This is likely due to either Asterisk or Zoiper not supporting these encryption standards.

Caveats

A few caveats and workarounds were used to get this setup working properly. The first was trying to get the servers registered to each other using TLS encryption. As mentioned previously, you must first register each server using the unencrypted configuration, then remove the registration line and use the TLS configuration. Most likely this is because of Asterisk, but it’s unclear why you need to register, but cannot register using TLS. Another caveat was turning of TLS certificate verification in the Zoiper settings.

When first attempted, TLS verification was on, but the phones could not call one another. After checking the setting, calling worked fine. Coming back to the setup and having the setting unchecked would still allow calls to be made. This is related to the use of self-signed certificates and not using an enterprise certificate authority.

Future Work

This TLS encryption setup can be expanded upon in the future. One problem large environments would have with this configuration is a certificate distribution problem. Cisco solves this certificate distribution problem by using the manufacturer certificate on their soft and hard phones, but Asterisk does not have that pleasure. There should be some form of certificate distribution, whether it be a central store or script that transfers each certificate to the required softphone to scale this properly. It’s also much easier to specify certificates in a soft phone compared to a hard phone. Adding a certificate to a hard phone would be difficult to say the least, but may be possible using a TFTP server. Expansion can come from using an enterprise certificate authority, such as the Microsoft a built-in certificate authority for Active Directory domains. When hard or soft phones are added to the domain and given a domain name, they will inherently trust the enterprise certificate authority, thereby allowing for certificate verification. Another issue would depend on what softphone the company uses; different soft phones would have different configurations and settings to get this setup working. Most companies also connect to a sip provider or internet telephony service provider (ITSP). You could expand this set up by adding TLS encryption to the SIP trunk between your network and your ISTP. As mentioned in the beginning of the post, the PJSIP module will most likely be used in the future due to its powerful potential. Converting this setup to use PJSIP instead of the SIP module would make the setup more future-proof. Asterisk includes a script to convert a SIP module configuration to a PJSIP configuration. In testing, this did not work immediately, so more testing would be needed to get PJSIP TLS working properly.

Conclusion

End the end encryption and transport encryption is certainly doable in Asterisk. However, it was very difficult to figure out and there was very little in the way of documentation. Multiple sources of documentation were used, in addition to testing, to get this setup working properly. Overall, this was designed to act as a centralized location for documentation regarding end-to-end VoIP encryption with Asterisk.

Acronyms

 

VoIP- Voice over IP

CUCM – Cisco Unified Communications Manager

PBX- private branch exchange

SIP- session initiation protocol

TLS- transport layer security

RTP- real time protocol

SRTP- secure RTP

CA – certificate authority

SDP – Session Description Protocol

SDES – Session Description Protocol Security Descriptions

ISTP – Internet Telephony service provider

Resources

• https://wiki.asterisk.org/wiki/display/AST/Secure+Calling+Tutorial
• http://www.asteriskdocs.org/en/2nd_Edition/asterisk-book-html-chunk/connecting_two_asterisk.html
• http://www.asteriskdocs.org/en/3rd_Edition/asterisk-book-html-chunk/OutsideConnectivity_id291235.html
• https://asterisk-pbx.ru/wiki/asterisk/pjsip-tls-srtp
• https://www.voip-info.org/wiki