Friday, August 30, 2013

Create Your Own Fishbowl, An NSA Approved Telecommunication Network


With all the media attention about government spying, NSA data collection and intercepts, FISA courts, Snowden, etc... people are finally waking up and realizing that they need to take steps to actively protect themselves on the Internet. As society becomes more and more connected, the possibility of data theft and corruption grows even more. Be honest though. Are you really surprised?
Now with that out of the way, what technologies are out there that can help safeguard us safe from the government, crooks, and nosy neighbors? The obvious answer is encryption, and layered security. How can we apply this to telecommunications that will work for us on the go and at home? The NSA actually was kind enough to provide us with the specifications needed to build our own clone of an infrastructure that is trusted to protect up to Top Secret classified material and communications.

The NSA's Mobility Capability Package

In 2012, the NSA presented their 100 page document describing the Mobility Capability Package to RSA Conference 2012. In order to spare you the details of 116 pages of agency and technical speak, here are the basic components of MCP.

  • Secure Voice Over IP (SVoIP) must have the following requirements
    • Network must be based on an IPsec VPN
    • SIP must use TLS to encrypt signaling exchange
    • SRTP will be used to encrypt voice communications
  • Secure Browsing must have the following requirements
    • Network must be based on an IPsec VPN
    • Servers will enforce TLS connections
    • The web browser on the User Equipment is configured to prohibit the storing or caching of any data in non-volatile memory.

For the time being, we're going to disregard the requirements for web, email etc. We're solely focused on the SVoIP and VPN setup. I know that the requirements now state the use of an IPsec VPN, but the original requirements they planned on using an SSL based VPN. Due to inter-operability issues with proprietary SSL VPNs, the NSA elected to go with IPsec. For ease of setup and use, we're going to use OpenVPN for this article, which of course is an SSL VPN.

Our Requirements

  • Computer hosting OpenVPN as a server
  • Computer hosting Asterisk as a server
  • Client running OpenVPN client configuration
  • Client running VoIP software capable of using TLS + SIP + SRTP
This configuration can be used for secure communication with end to end PCs and cellular telephones alike (iOS and Android both have VoIP clients in their respective stores that support SRTP and SIP + TLS.)

Setting up OpenVPN

Whether you choose to run OpenVPN and Asterisk from your desktop, on a Raspberry Pi, in a virtual instance, on a VPS, or a dedicated solution, go ahead and prep your environment. For consistency sake, I'm going to show the commands to do the setup on a Debian based distro.

Install OpenVPN

sudo apt-get install openvpn

Set up your own Certificate Authority (CA).

We already discussed that PKI is a requirement for our little project, because we're not going to use a static configuration due to security concerns. This allows each client to have his/her own public/private key pair. The first step is to setup our own local Certificate Authority (CA). Fortunately, OpenVPN comes with a tool suite designed to keep PKI management simple. It's called "easy-rsa." Now, depending upon your distribution and packaging system, it may be installed in various directories. For Debian, it's /usr/doc/openvpn/examples/easy-rsa/2.0. Go ahead and copy that directory into your VPN user's home directory.
# cp -r /usr/doc/openvpn/examples/easy-rsa/2.0 ~/easy-rsa
# cd ~/easy-rsa
Now, using your favorite editor, open up the file named vars.
# vi vars
As you can see, you can define key length and other variables associated with the keys that will be generated while using the easy-rsa suite. Go ahead and make any changes that you feel necessary for this step. You will be asked again if you want to change any of the variables listed at the bottom during the key building process.
Now we're going to build the actual CA certificates with the following commands.
# . ./vars
# ./clean-all
# ./build-ca
Follow the prompts and change anything that you may have forgotten about in the vars file.

Build OpenVPN Client / Server & DH Keys

# ./build-key-server fishbowl
# ./build-key client1
# ./build-key client2
# ./build-dh
Again, follow the prompts for each command in order to generate the required key pairs.
It is important to note that each private key (file type ends in .key) must be protected in order to maintain network integrity. Key exchanges must be conducted across secure lines of communication. This could involve directly handing over the keys in person on an encrypted device, it could be a prearranged symmetric cryptography solution, it could be anything only limited by your imagination.

Configure OpenVPN Server File

I have an example configuration available over on Github. If you'd like to change any of the variables, please do so at this time. You can change listening address, LAN IP space, key locations and so on. Save the server.conf file to /etc/openvpn/server.conf. Now we need to pull in the keys we previously created using easy-rsa.
# cp -r ~/easy-rsa/keys /etc/openvpn/keys
# chmod 700 /etc/openvpn/keys

Start OpenVPN Server

# openvpn /etc/openvpn/server.conf

Configure the Client for OpenVPN

As previously discussed, transferring private key requires a great deal of thought and security. You should have a chosen method for key distribution (one that involves physical mediums and not transmitting the keys over plaintext protocols), and sent the clients the following files.
  • client.key
  • client.crt
  • ca.crt
  • fishbowl.conf
For my example fishbowl.conf, just clone the github repo over at Fish Bowl Configs. You will need to change the server IP address in order to match it back to your own OpenVPN server.
You now have a fully functional VPN configuration. Generate as many client keys as needed, and send them the appropriate configuration files. Now, its time to move on to Asterisk.

Setting up Asterisk

Asterisk is a full featured, open source PBX solution that includes all of the supported features that we require for this exercise. First of all, we're going to go ahead and install Asterisk onto our respective servers. Again, you can host this on the same box as the VPN or on any number of platform choices. If you're going to run it on another computer, you'll need to generate VPN keys so that it can connect through the VPN. Use the previous steps to set this up. I am again giving the commands for installing this on a Debian based system. For my configuration, I'll be placing the Asterisk box on the same server as OpenVPN. Keep this in mind, and change your IPs / Network segments accordingly.

Installing Asterisk

# apt-get install asterisk

Generate TLS keys for use with SIP

Now we will generate the required keys in order to use TLS to encrypt our SIP signalling. First we need to create the directory to store our keys in. Similar to OpenVPN, Asterisk also comes with its own scripts to help ease the task of creating cryptographic keys. The script comes in "contrib/scripts/ast_tls_cert." In case you're using the Debian packages, I've included a copy in the github repository. You'll be asked for a password to be using with the Certificate Authority for signing additional keys. Pick something secure that you'll be able to remember in the future as well.
# mkdir /etc/asterisk/keys
# ./ast_tls_cert -C -O "Fish Bowl Communications" -d /etc/asterisk/keys
This created quite a few files under /etc/asterisk/keys. The ca.crt is important, because it will be required in order to distribute to the clients. We also still need to create additional keys for the clients in order for them to be able to communicate with Asterisk. Go ahead and create two certificates for client1 and client2 respectively.
# ./ast_tls_cert -m client -c /etc/asterisk/keys/ca.crt -k /etc/asterisk/keys/ca.key -C client1 -O "Fish Bowl Communications" -d /etc/asterisk/keys -o client1
# ./ast_tls_cert -m client -c /etc/asterisk/keys/ca.crt -k /etc/asterisk/keys/ca.key -C client2 -O "Fish Bowl Communications" -d /etc/asterisk/keys -o client2
After completing the above steps, you can see that the following files were created in /etc/asterisk/keys.
  • asterisk.crt
  • asterisk.csr
  • asterisk.key
  • asterisk.pem
  • client1.crt
  • client1.csr
  • client1.key
  • client1.pem
  • client2.crt
  • client2.csr
  • client2.key
  • client2.pem
  • ca.cfg
  • ca.crt
  • ca.key
  • tmp.cfg
In order for the clients to be able to connect, you need to add client1.pem or client2.pem (depending on the client) to their computer along with ca.crt. We'll cover client configuration later.

Configure sip.conf

Now that our certificates are in order for SIP, we'll go ahead and walk through the configuration of SIP in Asterisk. Open up /etc/asterisk/sip.conf with your favorite editor and lets get to work. Remember, all of my configs can be downloaded over on the FishBowl github
The first section you're going to come to that needs to be changed is the UDP/TCP bind area. You can comment out the sections dealing with bind address for both, because we are going to require that TLS be used as the transport medium. Once you come across the the lines regarding TLS configuration, we need to start making changes. Make sure that you substitute for your own IP address.
Ensure that TLS is enabled, and change the bind address to match your VPN IP respectively. We don't want it listening to external interfaces in order to minimize the chance of data leakage.
Once it gets to the transport medium, we want to force TLS only. Normally the options are TCP or UDP.
There's another option to further help us lock down who is able to use the Asterisk server. Again, change the IP and Netmask to match your VPN settings. The allowguest denies contacting anyone not associated with the VPN.
The last main option that we need to change other than adding clients in our case is to FORCE real time media streaming encryption with SRTP. The call will drop if both parties do not offer SRTP support.
Setup two clients in the SIP config at the bottom of the file.
context=local      ; this will be used in extensions.conf
allow=g722         ; choose the codecs that you prefer here.

context=local      ; this will be used in extensions.conf
allow=g722         ; choose the codecs that you prefer here.
Now we are able to login to the Fish Bowl Communications Network. We cannot however place any legitimate calls, until we setup the extensions.

Configuring extensions.conf

We're only going to cover the most basic of extension configuration in this article, as the sole focus is not on the Asterisk system. Books have been written and dedicated to that subject already. Open up extensions.conf, and go down to the [local] section, because that is the context that is given to both client1 and client2. We're simply going to add a Dial call routine and add an extension for each of the SIP clients.
exten => 100,1,Dial(SIP/client1)
exten => 101,1,Dial(SIP/client2)
The above configuration will dial client1 if anyone dials extension 100 and client2 if anyone dials extension 200. The 1 here indicates that it is the first step in the call process. Asterisk allows you to setup extensive voice prompts and menus for callers as well as setup conference bridges, fax documents, voice mails, call parking lots etc etc. This will however meet our BARE requirements in making secure phone calls over a VPN with fully encrypted SVoIP. Keep in mind that we need to safeguard keys when transferring them, and client1.pem/client2.pem both contain private keys along with the client certificates.

Client Configuration

There are multiple clients available across various platforms that support TLS + SRTP communication methods. I'll show an example of configuring SFLPhone for Linux based systems. The Asterisk wiki contains a good demonstration of setting up Blink on Linux, Windows, or Mac. See resources at the bottom for Blink configuration. If you're using a mobile client, these same principles will apply, and setup on multiple clients should be pretty straight forward.


Go ahead and install SFLPhone, if you're using Debian based systems, the following will get you started.
# apt-get install sflphone-gnome
Once the client is installed, go ahead and start it up. You can use the configuration wizard in order to get you started with configuring the account. Further manipulation will be necessary though. The first screen is a welcome message, press Continue to go on.

Register an existing SIP or IAX2 account

SIP (Session Initiation Protocol)

Fill out Client Information as Shown

No STUN Server is Needed

Click Apply and then Close. This is as far as the configuration wizard will take us. From here, we need to go to Edit Menu -> Accounts. Select client1 from the list and click on edit.

Click on the security tab. For SRTP exchange select SDES. Then select "Use TLS Transport(sips)" and click on Edit.

Once you're to the advanced security settings, this is where you select the ca.crt and client1.pem files in order to allow TLS to associate your client with the server. Server name should be the Asterisk box, and the default port is 5061 (unless you changed it in sip.conf). Your settings should generally look like the following.

That's it for client configuration. Go ahead and click apply, and select / deselect the option next to client 1 under the accounts menu. Once it associates with the server, you should see a message stating that you are "registered" with the server. Assuming that client2 is also connected, go ahead and give him a call and test out the audio (remember client2 is extension 101 as we set it earlier.) You may need to switch up codecs depending on connection speed and application.

Going beyond

The possibilities are truly endless when it comes to customizing these configurations. One thing that is nice to have is an analog phone converter like the Linksys PAP2T. This type of device allows you to use a normal telephone with the same secure setup. Ensure that your converter supports both TLS and SRTP, if you're going to use this setup. Experiment with adding phone bridges, trunking multiple Asterisk boxes together across the VPN. This article should have provided you with enough information to get you up and running. If you want more specific details, go to the respective wiki links as both Asterisk and OpenVPN have great support networks.



  1. Ends up that Microsoft and Google ( and have decided not to accept self signed certs for, or certs from a free authority like for pop/imap servers. It's better to transmit your password unencrypted I guess.

    1. Certainly better to send unencrypted everything if M$FT and Google are passing it off to the NSA anyway.

  2. Thank you for the info, but if you have your own server can't they just monitor the end node of that server? wouldn't it be better to like randomize servers, like a huge list of VPN servers and keep switching. if that is possible of course, like the TOR network but more secure.