Communication in the post-PRISM world

PRISM Break – Part 1

© Lead Image © Kirsty Pargeter,

© Lead Image © Kirsty Pargeter,

Article from Issue 155/2013

Linux users didn't need the recent NSA eavesdropping scandal to convince them that securing communication was a good idea. Free software developers have been creating secure tools for years that offer similar functionalities to all of those popular but very leaky services with ridiculous names.

The old Internet adage – "if you're not paying for it, you are not the client, you are the product" – holds true for every single service on the Internet. The information that you upload to popular social networks, store on clouds, and transfer through popular commercial communication networks is a prime candidate for harvest, storage, analysis, and use by the creators of the services, as well as (as is now known), government security agencies.

If you want real confidentiality, you must avoid all the obvious popular and free (as in beer) options that already have proven untrustworthy [1]. In other words, if you are serious about keeping your data private, you should steer clear of services such as Facebook, Hotmail, Skype, YouTube, Dropbox, and the like (this is the first level of confidentiality). You should also use only open source software (a second level of confidentiality), because it is the only software that is audited frequently by independent, non-biased third parties. A third level of confidentiality is that you should be able to host the servers that process and store your data yourself.

Now, some people might disagree here. Many sys admins will argue that hosting your own stuff in-house to defend your privacy is not a good idea. They will say that supporting servers is a full-time job and that most small office and home office (SOHO) setups are not as secure and fault tolerant as professionally maintained server farms at hosting companies. They would be right; however, I am not arguing security here, but confidentiality, and those are two different things.

A server farm will have backup systems, high levels of software and hardware security, and expert personnel to keep your data safe from the bad guys and protect from accidental erasure. However, a server farm is also more likely to be the target of malicious hackers and the secret laws, courts, and subpoenas you've heard so much about lately. A hosting company might be subject to a gag order as well as a subpoena, so, if you host your data with a third party, you might already have an NSA flunky's grubby paws on your family photos, recordings of conversations, and private medical records, and you would not even know about it. If, however, a government agency wanted information from your own servers and decided to obtain it in a legal fashion, you would be the first to find out.

Of course, such an agency could just get an order to wiretap your communications without your knowledge, but, first, remember that they can do that with a third party hosting your data as well. And, second, that's why encryption was invented.

Rules of the Game

In view of the above considerations, the post-PRISM software presented in this series of articles had to follow certain rules to make the grade. To begin with, all servers and clients had to be open source to comply with the second level of confidentiality mentioned above. They also had to be installable on a regular server without requiring additional special software or hardware to comply with the third level of confidentiality.

As for "hardware," I chose a boilerplate stable and updated Debian server installation on a VirtualBox virtual machine. When installing Debian, I chose the server option (databases, web servers, etc.). All extra software needed to satisfy dependencies is listed in the article and, in general, is culled from Debian's official repositories. Note that I deliberately did not include any repositories that contained proprietary software, such as non-free.

I avoided third-party software and services as much as possible, and when I was forced to communicate over third-party services (e.g., an ISP's network), I made sure that the software provided point-to-point encryption.

The Case Against Skype

One company stands out as a having a total disrespect for its users' confidential data, and that is Microsoft. It was one of the first to take on board the requirements of the PRISM program and has helped the NSA access email on Outlook and Hotmail at the pre-encryption stage. Microsoft also gave the agency access to their cloud storage service, SkyDrive, which hosts data from more than 250 million users. Additionally, the company has delivered vulnerability data to US government security agencies so that the data can be then used against users who didn't even know their software was leaking.

As for Skype, in one of Edward Snowden's documents published by The Guardian, the NSA gloats about how the number of calls intercepted on the service tripled once Microsoft took over [2]. So, if there is one service to avoid in an attempt to improve confidentiality with your family, friends, colleagues, and clients, it's Skype.

Your Own Secure Skype

The good news is that three very interesting contending technologies are available for audio/videoconferencing. The bad news is that, at the time of writing, two of them don't work that well, at least not in a way that is useful to your average SOHO setup. Although it's now 2013, apparently audio- and videoconferencing are still very hard to do. Popular, but proprietary technologies, such as Skype and Google Hangouts (originally GTalk), seem to have sucked users (and, hence, developers) away from open source alternatives.

The first alternative is Jingle [3], which is an attempt to bring an audio/video layer to XMPP, the technology behind Jabber. Jabber/XMPP is the base for the most popular messaging services out there, such as WhatsApp, and it works very well for instant messaging but not so much with audio/video.

Jingle [3] was added as an afterthought to a protocol that was never intended to carry videoconferencing in the first place. In theory, a Java-based client, Jitsi [4], already exists, and you can try it out on the public server at Jitsi's site. The fact is, however, that the client is very buggy and capricious about what it will connect to without throwing an exception-laden fit. Although Jitsi and the Jingle protocol are developing rapidly, the combination is not a good first choice for a production environment.

The second proposal is WebRTC [5], a technology developed jointly between Google and Mozilla that intends to make videoconferencing possible via a web browser (Figure 1). To set things up, you run a server from your machine and include a set of JavaScript modules into a specially designed web page. You can then visit the page with your WebRTC-enabled browser [6] – at the time of writing, Chrome, the Firefox nightly build, and Chrome Beta for Android – and enjoy a hangout-like videoconference. This is an interesting idea, and you can play with some demos of the technology online [7], but, in fact, it has several drawbacks: No stable version of a server is yet available, configuration is difficult and underdocumented, you must depend on some "secret" Google services, and all the bits and pieces are still under heavy development, so they are subject to change.

Figure 1: WebRTC is interesting, but it is still in early development and quite buggy, as the screen capture shows.

The third technology – the one that really works and works now – is based on Session Initiation Protocol (SIP). It is what VoIP is made of, and although it may seem overkill to set up a whole SIP system to get confidential audioconferencing, it seems for now to be the most reliable way to give Skype the boot.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More