Once you have your FreePBX/Asterisk server up and running, what do you need to do to start using encryption to protect your phone calls?

1) You are going to need a certificate. I am not doing a PKI tutorial here -- there are enough out there on the web. Keep in mind that your phones -- soft or hard -- will need to trust your CA.

2) Asterisk must be compiled with SSL and SRTP support.

3) SIP Settings in FreePBX or sip.conf:

tlscertfile=/var/lib/asterisk/keys/myCertandKey.pem (key and cert concatenated in one file.... lame, I know, so make sure perms on that file are 400.)

(One day, I hope there's a hard phone that does TLS 1.2 with ECDH and AES-GCM.)

4) Extension Settings in FreePBX or sip.conf :

encryption=yes (SRTP Only)

5) SNOM Phone Settings:

registrar: my.asterisk.server;transport=tls

RTP Encryption: on
SRTP Auth-tag: AES-80
RTP/SAVP: mandatory
Media Transport Offer: TCP

Upload your CA's public cert.

 6) For Trunks (assuming the other end is in your circle of trust):

Refer to the Asterisk Wiki.

7) As long as you have a cert and key for Asterisk, you may as well use the same one for   the web interface. You'll need to install mod_ssl:
yum install mod_ssl
and then edit /etc/httpd/conf.d/ssl.conf to point to to your certificate files above. Otherwise your admin passwords go across the network in the clear.

8) Consider adding real CentOS repos to your install instead of sticking with just the FreePBX repos. It will certainly void your warranty, but you'll have up-to-date software.

9) Test with Cain.

10) Understand that confidentiality is not at the top of the priority list for Asterisk or FreePBX, although that is changing... It's enough to make you want to try FreeSwitch.

In recent days, this blog has seen an increase in traffic to entries on Asterisk and Encryption. So you're wondering if you can use OpenSSL and Asterisk to keep your phone calls private. The answer is, it depends. To keep calls private, you'll need to secure the PBX, the phones, and the connections between them.

The good news is that Asterisk is more stable than ever, and it supports OpenSSL. SIP-S behaves pretty much like https does on Apache's web server. SRTP's source code is available, although SRTP has had far less scrutiny into its encryption implementation. (I am unaware of any FIPS-140 validated SRTP modules.) Why two different forms of encryption? This is an important point:

  • SIP-S encrypts just the registration and call control data. This includes extension, username, password (beyond Digest), and the phone number you're dialing. The use of digest authentication in unencrypted SIP across the Internet is a critical flaw. While digest hashes your password with MD5 with a "nonce" or salt, the nonce is sent in the clear. CAIN can crack a 4-digit password captured in digest form in less than one second.
  • SRTP covers the contents of the call to include your voice back and forth. The key for SRTP is negotiated in the SIP channel, so doing SRTP only is pointless. (Select an 80-bit key for SRTP if possible.) SIP-S protects your username and password and the number dialed, but not what you're saying or hearing. In summary, you need both SRTP and SIP-S/SIP-TLS to keep your calls private.

Keep in mind that anyone eavesdropping on your network connection will still know there's a call in progress and the IP addresses of your endpoint/hardphone/softphone and your Asterisk server even if you're using both forms of encryption. In general, it's a good idea to encrypt your calls locally, because it's fairly trivial (CAIN) for your Network Admin to configure a span port and start recording all your calls to disk. Also keep in mind that monitoring is a feature of Asterisk that can be enabled. If you can't secure your server, your calls won't be private.

What about the other side of the call? Who are you talking to? How does your call get there? If you're using a commercially provided SIP trunk to get to the PSTN and dial real phone numbers, it's pretty much over right there. Few low-cost SIP providers support SIP-S or SRTP. Even if they do, they still need to fill out FCC Form 445 and FCC Form 449. 

FCC Form 445 is used to monitor the progress of telecommunications carriers that provide facilities-based broadband Internet access or interconnected Voice over Internet Protocol (VOIP) services in complying with the Communications Assistance for Law Enforcement Act (CALEA) and the Commission's requirements for such facilities and services. See Communications Assistance for Law Enforcement Act and Broadband Access and Services, ET Docket No. 04-295, Second Report and Order and Memorandum Opinion and Order, FCC 06-56 (released May 12, 2006), 21 FCC Rcd 5360 (2006) (Second Report and Order). See also 47 C.F.R. § 1.2000 et seq.

FCC Form 449 and background:

With very limited exceptions, all intrastate, interstate, and international providers of telecommunications in the United States must file this Worksheet. Telecommunications providers that are contributors to any of the support mechanisms, including USF, TRS, NANPA, or LNPA, must file this Worksheet. The term "telecommunications" refers to the transmission, between or among points specified by the user, of information of the user's choosing, without change in the form or content of the information as sent and received. For the purpose of filing, the term "interstate telecommunications" includes, but is not limited to, the following types of services: wireless telephony, including cellular and personal communications services (PCS); paging and messaging services; dispatch and operator services; mobile radio services; access to interexchange service; special access; wide area telecommunications services (WATS); subscriber toll-free and 900 services; message telephone services (MTS); private line; telex; telegraph; video services; satellite services; resale services; Frame Relay services; asynchronous transfer mode (ATM) services; Multi-Protocol Label Switching (MPLS) services; audio bridging services; and interconnected VoIP services.

The keyword here is "interconnected." Also, "non-interconnected:"

Non-Interconnected VoIP Service Providers: All providers of "non-interconnected VoIP service" (as defined in section 64.601(a) of the Commission's rules) with interstate end-user revenues subject to TRS contributions must file this Worksheet in order to register with the Commission and report their revenues for purposes of calculating TRS contributions.

Unless you're Google Voice, in which case you don't have to follow the rules. This may explain the reluctance of Google to make Google Voice an "official" business app.

Back to your phone calls: if you're paying anyone else to provide anything to your phone call other than a raw internet connection, they have to register with the FCC and certify that they can provide monitoring to the government. Form 445 requires a reference number from Form 449-A so they can check. Actuallly, your broadband provider needs to do this too, so what can you do? To make private calls, they need to connect through PBXes that you control. No PSTN calls are private, ever.

So if you're going to make a secret squirrel phone call to your buddy using Asterisk, that buddy's phone had better be a client of the same Asterisk server, or you need SIP or IAX2 trunks you both control, between Asterisk servers you both control, with encryption. Yes, you can encrypt SIP and IAX2 trunks, per Asterisk docs. Even better, use VPN between the two Asterisk servers, so you have two layers of encryption. That way, a single flaw in SIP-TLS, SRTP, or OpenVPN/IPSec won't be fatal. (Some call it "swiss-cheese theory:" if you have two layers of swiss cheese, the holes probably won't overlap. Using VPN for all SIP traffic - trunks and calls - can prevent you from exposing servers and phones on the Internet. SIP scanning is one of the most common attacks I see with Snort. It's best not to leave any VOIP ports open to the Internet. Use VPN for trunks and clients.

Even with SIP-S, SRTP, and OpenVPN or IPSec, though, network traffic analysis will reveal the connection, or association, between IP addresses. You and your co-conspirators are visiting the same server, so if one of you is a target, your buddies become targets, too. Suddenly, everyone who connects to your secret squirrel Asterisk server is suspicious. While the content of your communication is secure, the IP traffic to and from your PBX reveals your whole criminal team. Now you know why numbers stations  are still in use in 2013, along with one-time-pads on flash paper. Before online gambling, bookies use to keep their betting slips on flash paper.

How to build Asterisk?

From source, of course. (Although the latest stable version of the  FreePBX distro has SSL and SRTP support compiled in and OpenVPN installed in CentOS 6.3, but an antique version of OpenSSL -- OpenSSL 1.0.0-fips 29 Mar 2010.) My last Fedora (Spherical Cow) install had every prerequisite installable from Yum. You could build all the prereqs from source, but that takes a while. (If you're on Amazon's cloud, it will be necessary for quite a few of them.) Then stop with RPMs. Do not use RPMs for Asterisk.  Build Asterisk from source. There are too many options that need to be compiled in, from SSL to SNMP and SRTP. You can also see what's really getting built. Asterisk has a nice menuconfig that will let you know what you're missing.

For the uninitiated:

  1. Wget http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-11-current.tar.gz
  2. Tar -zxvf asterisk-11-current.tar.gz
  3. Cd asterisk-11-current
  4.  ./configure
  5. Make menuselect (and then choose your options, including SRTP.)
  6. Save and exit
  7. Run mp3 script here: asterisk-11-current/contrib/scripts/get_mp3_source.sh
  8. Make
  9. Make install

You could try building OpenSSL from source and then building Asterisk from that rather than the RPM/Deb package that came with your distribution. Then you can update it on OpenSSL's schedule rather than Fedora's. I'd complain about not getting TLS 1.2 or elliptic curves and keys, but I'm pretty sure no phones around support it. Snom phones support RC4, RSA, DH, and SHA-1, but not CRLs.

What kind of hard phone to use? The SNOM phones work best in my environment. They can even do OpenVPN before registering with your Asterisk server. However, I've had issues doing OpenVPN and SIP-TLS simultaneously because of DNS issues. (PFSense, an open-source firewall, supports OpenVPN and even has a profile export module for SNOM phones.) And unlike the Nortel phones, there's no "ringless monitoring extension" feature on SNOM phones that lets your admins place your phone's microphone and camera off-hook silently.

However, you're going to have to trust the firmware on any phone you get. Not just that it doesn't have a back door, but also that it's implementing encryption well. Some Cisco phones have FIPS-140 certification, but the SNOMs do not. (FIPS certification means the encryption has been implemented well, but it doesn't mean the phone is impervious to attack, as shown here.) The trouble with the Cisco FIPS phones is that you really don't want to try SIP out on them. Cisco small business phones support SIP, but they're not using FIPS certified encryption modules. What about soft phones? In general, general-purpose computing devices are more likely to be hacked. A Windows or Mac computer is more likely to have a virus than a VOIP hard phone -- the attack surface is larger. However, you may not have a choice if you want to try a secure call from your smart device. Fortunately, there's OpenVPN for iOS and Android now.

Other risks:

  • Are you making the call with your computer? FAIL. Your computer is infected and copying all the data someplace else.
  • Are you talking near a computer? FAIL. Your computer is infected and recording audio and video from your webcam.
  • Are you talking near any other type of phone - landline, mobile? FAIL. The phone has been placed off-hook remotely and audio is being recorded.
  • Are you talking in public? FAIL

Did you know you can still buy rabbit ears for your TV? My last scan through our airwaves with a $12 RCA antenna got me 33 channels to choose from. It out-performed my rooftop antenna and/or its old cabling. I think that’s more channels than used to be available on basic cable.

These listings are as-observed from my location. Your reception may vary. Getting Channel 26 required some micro-adjustment of antenna.

Given an Internet connection and an antenna, will cable maintain its relevance? Cable’s value proposition is dwindling as other programming options increase and the population ages.

Number Station Network Format Notes
4-1 WRC-HD NBC 1080i 16:9
4-2 WRC-SD COZI 480i 16:9 boxed
5-1 WTTG-DT FOX 720p 16:9
7-1 WJLA-HD ABC 720p 16:9
7-2 WJLA-WX 480i 4:3 Weather Radar
7-3 WJLA-WN 480i 4:3
9-1 WUSA-HD CBS 1080i 16:9
9-2 WUSA BOUNCE 480i 4:3
9-3 WUSA 480i 4:3 Weather Radar
14-1 WFDC-DT Univsion    1080i 16:9
20-1 WDCA-DT 720p 16:9
20-2 MundoFx 480i 16:9
26-1 WETA-HD PBS 720p 16:9
26-2 WETA-UK 480i 4:3
26-3 WETA KIDS 480i 4:3
26-4 WETA TV-26 480i 4:3 Same programming as 26-1
30-1 MHz1 480i 4:3 Brit Drama
30-2 MHz2 480i 4:3 NHK News
30-3 MHz3 480i 4:3 CCTV News
30-4 MHz4 480i 4:3 Russia Today
30-5 MHz5 480i 4:3 Al Jazeera English
30-6 MHz6 480i 4:3 CCTV Documentary
32-1 WHUT-HD 1080i 16:9
32-2 WHUT-SD 480i 4:3
49-1 Unknown 480i 4:3 Color Bars
49-2 NT-DTV 480i 4:3 Chinese Programming
50-1 CW50 1080i 16:9
50-2 AntTV 480i 4:3
50-3 ThisTV 480i 4:3 thistv.com
66-1 WPXW ION 720p 16:9
66-2 WPXW qubo 480i 4:3 kids programming
66-3 WPXW IonLife 480i 4:3
66-4 WPXW ShopTV 480i 4:3

Unlike the FAA, the NTSB permits anyone on the Internet to download their entire database of aircraft incidents and accidents. The NTSB's file is simple: one table contains all fields, and their data dictionary explains the fields. The URL to the narrative at the NTSB's site is included for quick report access. I downloaded that file and converted it into a KML file for Google Earth. The event icons are color-coded: blue for incidents, orange for non-fatal accidents, and red for fatal accidents. Unknown events get the default GE pushpin.

CLICK ON THE ICONS IN GOOGLE EARTH FOR MORE INFORMATION. (Seriously, a lot of people miss this and don't get most of the information.)

I did not have to do any geographic math on latitude and longitude. It's in decimal format in the NTSB downloadable, unlike the FAA which has at least two different lat/lon formats in every file. Not all location information is correct, but most of it is. (An example is N6ZV.)

Unfortunately, not all events have been geocoded. Twenty-seven percent, or 19,706 of the total 72,571 events in the NTSB database do have latitude and longitude, and those are contained in the KML file along with other details of the event. Please note that in Google Earth, you need to click on the icon to get the details. (Some people just look at all the items but do not click and miss most of the useful information.)

Looking at the file in Google Earth, the obvious becomes apparent: Most incidents and accidents take place at airports. Out west, a planes don't always make it over mountains. Looking at red sites is also a little creepy.

The idea to map aircraft accidents into a KML file grew out of my imperfect recollection of accidents at nearby airports. I remembered one accident at a nearby airport (ANP), but not the details. If you're going to use all available information to brief yourself, then NTSB accident information for an unfamiliar destination airport might prove useful. You don't need this file and Google Earth to do it -- you can use the NTSB's site. Using the GE, however, might help you identify problem areas.

If I update the KML file (NTSB data is updated monthly), it will go into the KML archive.

I updated the Military Training Routes KML file as well as the Special Use Areas KML file on the Sept. 20 FAA data cycle. Both are in the KML folder here.

I also found an interesting new site that has more KML files available, as well as an MTR KML file with a different data source. This is the first time I've been able to check my work against anyone else's. In Google Earth, it's very easy to have two layers and compare them.

The source on the other file is the DoD's DAFIF file, which is now FOUO. That's For Official Use Only, as in not for public release.

The BLM (Bureau of Land Management, part of the Department of the Interior) has an inter-agency airspace coordination site to help coordinate flight restrictions around forest fires. Under that site is a directory of KML files.

The MTR information is close on both files, with the exception of "Slow Routes." I guess the DoD's DAFIF files include "Slow Routes" but the FAA's text data has no such type of MTR listed.

I use David Flater's Xtide tide prediction software to view tide levels when I go to the beach. His updates the tide database periodically, and when that file is updated, the location numbers can change. Thus, I need to update the Xtide KML file that displays those locations. There are 4,527 locations (both reference and sub) in the latest harmonics file, dated March 2, 2012. The file contains locations both north and south of the equator.

After noticing that the FAA had reduced the line length of their Military Training Route text file from 553 characters to 520 characters in their April release, I knew that I had some cleanup work. They also created a new type of record, separating out the agency data from the base MTR record into its own type. Database folks would call these tables. Who says they government can't change? This makes creating the KML a little easier, because I'd rather parse more record types with fewer fields than fewer record types with more fields.

Fun facts:

  • Pretty much everything the FAA writes is in ALL CAPS.

  • There are about 400 "noise-sensitive" areas that our military pilots need to know about, including at least nine chicken farms.

  • There are about 39 "CONGRESSIONAL" noise-sensitive areas, including several "CONGRESSIONAL (EXTREMELY) NOISE SENSITIVE AREA".

  • There is at least one "CONGRESSIONAL NOISE SENSITIVE AREA (CATTLE FARM)" at N36-28.8 W80-27.5. Who knew that sonic booms make milk go sour?


I am working on creating a KML sub-set to include just Congressional noise-sensitive areas, so we can all know which areas to avoid.

File Format Improvements:

  • SOP and other data are not commingled between IR and VR routes with the same number. Route Type and the number are a composite key.

  • Now includes terrain-following operations notes, if applicable

  • When you click on a line, you get a table of data rather than all freeform text.

  • When you click on a waypoint, you can see the Navaid distance and radial.

  • Waypoints are now star shapes instead of the stock pushpins.

The new Military Training Route file is in the KML Archive. The filename starts with "MTR".