Linux softphone comparison, Ekiga security analysis, and the snom 370

January 1st, 2009

Updated June 17th, 2009

In this series, we have set up Asterisk, OpenVPN and a business-quality SIP desktop phone. We also set up KPhone on Linux. Here's a quick comparison of the other softphones we tried in Linux.

KPhone

KPhone is easy to set up in Linux (apt-get install kphone) and easy to use. It's simple and well-integrated with Ubuntu. Unfortunately, it doesn't seem to be in active development, and it has one major drawback: it only supports in-band DTMF. This severely limits its codec choices. Most of the "good" codecs are optimized to compress the human voice by removing data which are imperceptible to the human ear. Unfortunately this makes these "good" codecs unusable with DTMF codes (and also modem and fax transmission). This isn't normally a problem with SIP. SIP has out-of-band signaling capabilities, which are more reliable than in-band (DTMF) signalling. But KPhone doesn't support these out-of-band signalling options.

Therefore, we must use the bandwidth-intensive ulaw codec. If there's plenty of bandwidth, that's not a problem. But if bandwidth is limited, such as when using a hotel's network, ulaw can result in dropped sound, or it might not work at all.

The other problem with KPhone is that we found it dropped calls very frequently. It was not reliable enough to be useful.

It's also Linux-only. Ability to use the same software on both Linux and Windows would be a plus, to support the entire user base with one application.

Linphone

Linphone is a more modern alternative to KPhone with video support and other features. Unfortunately I was not able to get it to register and receive inbound calls in my setup with OpenVPN. Outbound calls worked fine. Until it works better with registration with Asterisk, it's not a viable choice.

The winner: Ekiga

Ekiga wins. It's been around for a while, formerly as GnomeMeeting. Ekiga is under active development. It has support for many SIP capabilities, including video and (like all modern SIP software) out-of-band DTMF. When I originally wrote this article, I was unable to get Ekiga to register to receive inbound calls. However, after upgrading to Ubuntu 9.04 (Jaunty) I decided to try again. Jaunty comes with Ekiga 3.2.0, so that is the version covered in this review.

Installation was trivially simple; it doesn't get any easier than apt-get install ekiga. I configured OpenVPN as normal (see the other sections of this article). I did not turn on routing on the host, because Ekiga will be running on the host machine itself. If I had wanted to use the host (my laptop) to route OpenVPN for other machines, I could have turned on routing.

Ekiga (GnomeMeeting) account configuration

Getting Ekiga to register was also trivially simple. I added a block in /etc/asterisk/sip.conf to allow it to log in. Note: the section name in /etc/asterisk/sip.conf should be the same as the auth name the SIP client sends. I also added the extension in the appropriate places in my dialplan in extensions.conf. I went to the Accounts menu in Ekiga, and added the account, using 10.8.0.1 (the server's OpenVPN address) as the SIP registration server.

The Ekiga softphone registered as expected and I tested both incoming and outgoing calls successfully. It couldn't be any easier.

And Ekiga has other great aspects as well. It runs on both Linux and Windows, so we can use one softphone for our entire user base. It's simple enough that ordinary users can install it and use it. You can't beat the price. I'm looking forward to testing it out with video calls.

A security risk with Ekiga and OpenVPN

The one concern we have is the way Ekiga handles interface selection. In short, it tries them all. If the machine has interfaces 10.8.0.10, 192.168.1.101 and 222.122.122.12, Ekiga will send out registration messages on all three, with the registration IP address set to the interfaces' respective addresses. That's very convenient for users, because it means they don't even need to think about interfaces, and it's likely to "just work". However, this design could introduce some subtle and serious problems.

The normal threat model for network security is to imagine an attacker has a high level of control over the network between two end-points. Normally it is assumed that the end points are trusted, but the network between them is completely under the control of the attacker. OpenVPN, SSL and other secure network protocols are designed for this threat model. And in fact, this threat model is quite realistic. If a user is using a connection at a hotel or an Internet cafe, some untrusted party is in complete control of the network. Any secure communication protocol must be designed with this threat model in mind.

Imagine a configuration with Ekiga and OpenVPN. The mobile user is named Alice. Alice is in an Internet cafe or hotel, thinking, "OpenVPN gives me a secure connection, and Ekiga is going over OpenVPN, so this is a secure link to Asterisk." Alice is going to connect to Bob's Asterisk server. Unfortunately, Mallory the Internet cafe owner / network operator could make a successful attack as follows:

Mallory blocks OpenVPN traffic, so the VPN won't come up
Alice turns on her computer. The OpenVPN client software tries to open a tunnel, but fails, because Mallory is blocking it. Unfortunately it doesn't alert Alice, or Alice doesn't notice the alert of the failure.
Alice activates Ekiga on her computer. Ekiga sends out registration messages on all interfaces. Of course, the OpenVPN interface is down, but Ekiga has sent packets on the other interfaces, including the computer's physical interface (eth0 or wlan0).
Mallory intercepts the registration packet that Alice's Ekiga client sends out over Alice's non-VPN interface (eth0 or wlan0). Note that this packet is going to Bob's server's OpenVPN interface IP address, which is 10.8.0.1 in our configuration example.
Mallory now has several options. He has now captured Alice's registration credentials from that packet, and could attempt to register his own machine. Or he could configure his SIP server to accept the registration, leading Alice to think she has a secure connection to Bob's Asterisk server, when in fact she has a connection to Mallory's server. Mallory could configure his machine to act as a SIP proxy, so Alice could make and receive calls without realizing they are all going through Mallory's machine. Mallory might be able to use a NAT filter to alter the IP addresses in Alice's packets, allowing Alice's Ekiga to register itself on Bob's Asterisk server without needing to use a SIP proxy.

It's clear that Mallory has a reasonbly simple attack option: Block OpenVPN with a simple firewall rule, add a NAT rule to translate 10.8.0.1 into Bob's Asterisk server's real external address, and monitor SIP traffic with one of the many IP monitors which can capture and decode SIP. This attack is within the capability of even non-expert Mallorys.

There are a few non-obvious configuration settings that could and should be used to prevent this scenario from happening. First, Alice's computer should have a firewall that blocks all SIP traffic on all interfaces except tun0. That solves this problem. If Alice also needs to use Ekiga to connect to other servers, she could use a more specific firewall setting: drop all packets to 10.8.0.1 on all interfaces other than the VPN's tun0 interface. That rule is a good idea in general. Finally, Bob should configure his Asterisk server to not allow Alice to connect except on the VPN interface. He does this by putting bindaddr=10.8.0.1 in Alice's block of /etc/sip.conf.

It would be best if Ekiga had a configuration option to specify a particular interface. Ekiga had this setting in versions prior to 3.0. It's an important setting. Broadcasting out registration messages, with credentials, on all interfaces, is not a good security practice.

Snom 370

Unlike the other options in this article, the snom 370 is a hardware phone. It runs Linux, although users and administrators do not interact with Linux directly on the phone. There's no way to get a shell, for example.

But it is Linux, and users can download a software image that includes OpenVPN. We found it to be fairly easy to follow the instructions and configure both OpenVPN and SIP on the phone. The trick is to get OpenVPN working first. The easiest way to do that is to put together an OpenVPN configuration directory on a computer, test the tunnel to see that it works, and then move that configuration to the snom 370. At that point, configuring SIP is simple. Make it connect to the server's VPN end point, which is 10.8.0.1 in this series of articles.

The phone itself looks modern and professional, has all the expected features, has an easy-to-use web interface, and works well. I would recommend it for any office which needs a standalone phone that runs both OpenVPN and SIP. In fact, it can at as an OpenVPN router for other devices, by connecting them to its second interface. The major downside for offices considering deploying this phone is its high price. For an office with one phone, this phone makes sense. For an office with more than one phone, it would be more cost effective to have a dedicated OpenVPN client machine, and then connect simpler phones to that machine.

The only problem we encountered with this phone was we have experienced occasional software crashes, requiring the phone to be unplugged and rebooted. I suppose that when you have so much software in a device, there are more opportunities for reliability problems. I hope it will become more stable with future software updates.

Conclusion

KPhone worked, but seems to have stopped active development, and does not support out-of-band signalling. If there weren't any other choices, KPhone would be viable, but fortunately there are other choices.

I couldn't get Linphone to register properly and receive inbound calls.

Ekiga works very well, works on both Linux and Windows, and is easy to use. It's the obvious choice, although users do have to be aware of a security risk due to it binding on all interfaces.

The snom 370 is a good option for users who want a standalone phone that supports OpenVPN. The drawbacks of the snom 370 are high cost and also some instability.

If you need help designing and implementing a voice application or PBX based on Asterisk and SIP, contact us at 310 356 7869 to discuss.