Ian Sullivan showed me an article that he read about eavesdropping on Internet telephony calls. I'm baffled at the obsession about this issue on two fronts. First, I am amazed that people want to hand their phone calls over to yet another proprietary vendor (aka Skype) using unpublished, undocumented non-standard protocols and who respects your privacy even less than the traditional PSTN vendors. Second, I don't understand why cryptography experts believe we need to develop complicated new technology to solve this problem in the medium term.
At SFLC, I set up the telephony system as VoIP with encryption on every possible leg. While SFLC sometimes uses Skype, I don't, of course, because it is (a) proprietary software and (b) based on an undocumented protocol, (c) controlled by a company that has less respect for users' privacy than the PSTN companies themselves. Indeed, security was actually last on our list for reasons to reject Skype, because we already had a simple solution for encrypting our telephony traffic: All calls are made through a VPN.
Specifically, at SFLC, I set up a system whereby all users have an OpenVPN connection back to the home office. From there, they have access to register a SIP client to an internal Asterisk server living inside the VPN network. Using that SIP phone, they could call any SFLC employee, fully encrypted. That call continues either on the internal secured network, or back out over the same VPN to the other SIP client. Users can also dial out from there to any PSTN DID.
Of course, when calling the PSTN, the encryption ends at SFLC's office, but that's the PSTN's fault, not ours. No technological solution — save using a modem to turn that traffic digital — can easily solve that. However, with minimal effort, and using existing encryption subsystems, we have end-to-end encryption for all employee-to-employee calls.
And it could go even further with a day's effort of work! I have a pretty simple idea on how to have an encrypted call to anyone who happens to have a SIP client and an OpenVPN client. My plan is to make a public OpenVPN server that accepts connection from any host at all, that would then allow encrypted “phone the office” calls to any SFLC phone with any SIP client anywhere on the Internet. In this way, anyone wishing end-to-end phone encryption to the SFLC need only connect to that publicly accessible OpenVPN and dial our extensions with their SIP client over that line. This solution even has the added bonus that it avoids the common firewall and NAT related SIP problems, since all traffic gets tunneled through the OpenVPN: if OpenVPN (which is, unlike SIP, a single-port UDP/IP protocol) works, SIP automatically does!
The main criticism of this technique regards the silliness of two employees at a conference in San Francisco bouncing all the way through our NYC offices just to make a call to each other. While the Bandwidth Wasting Police might show up at my door someday, I don't actually find this to be a serious problem. The last mile is always the problem in Internet telephony, so a call that goes mostly across a single set of last mile infrastructure in a particular municipality is no worse nor better than one that takes a long haul round trip. Very occasionally, there is a half second of delay when you have a few VPN-based users on a conference call together, but that has a nice social side effect of stopping people from trying to interrupt each other.
Finally, the article linked above talks about the issue of variable bit
rate compression changing packet size such that even encrypted packets
yield possible speech information, since some sounds need larger packets
than others. This problem is solved simply for us with two systems: (a)
we
use µ-law,
a very old, constant bit rate codec, and (b) a tiny bit of entropy
is added to our packets by default, because the encryption is occurring
for all traffic across the VPN connection, not just the phone
call itself. Remember: all the traffic is going together across the one
OpenVPN UDP port, so an eavesdropper would need to detangle the VoIP
traffic from everything else. Indeed, I could easily make (b) even
stronger by simply having the SIP client open another connection back to
the asterisk host and exchange payloads generated
from /dev/random back and forth while the phone call is
going on.
This is really one of those cases where the simpler the solution, the more secure it is. Trying to focus on “encryption of VoIP and VoIP only” is what leads us to the kinds of vulnerabilities described in that article. VoIP isn't like email, where you always need an encryption-unaware delivery mechanism between Alice and Bob. I believe I've described a simple mechanism that can allow anyone with an Asterisk box, an OpenVPN server, and an Internet connection to publish to the world easy instructions for phoning them securely with merely a SIP client plus and OpenVPN client. Why don't we just take the easy and more secure route and do our VoIP this way?