22 June 2013

How to make secure, encrypted phone calls... for free

The ZRTP-capable
Groundwire app for iOS
Recent revelations have alleged wholesale governmental monitoring of phone conversations and emails.  Governments (plural) are reported to have real-time ability to access encrypted digital connections of all kinds, including Skype.  My own hypothesis, based on details in the the published allegations and known hacks of Certificate Authorities (on whose infrastructure the entire trust system of today's Internet is based), is that purloined Certificate Authority certificates are being utilized to allow inexpensive monitoring of communications transported over encrypted channels like SSL and TLS.  The key to privacy is to utilize encryption techniques which do not depend on the compromised Certificate Authority system.

VoIP is rarely encrypted at all, but that may be changing as dismayed citizens demand an end to suspicionless, warrantless surveillance.  Today, ostel.co (note: not .com) is a free/open-source project which implements the ZRTP communications-encryption technique which allows users to call each other securely and without cost over WiFi or other Internet connections.  Conference and video calls are also supported.  More info about ZRTP here.

Each participant must run a ZRTP-capable VoIP client on their computer or smartphone-- this is not something you can use a old-timey analog telephone with.  Clients are available for a variety of platforms including OS X, Windows, iOS and Android.  Some are even free!

Getting started making and receiving secure calls is simple: you sign up for an account at ostel.co and give yourself a user name.  You download the appropriate app onto your computer or smartphone and set it up to talk to your ostel.co account.  Your friends and associates do the same.  You then ring each other up using your respective user names, and validate a randomly-generated numeric code.  Pretty simple.

Documentation is sparse, to put it charitably, but here's how I got it working on OS X 10.8.4 Mountain Lion:

  • Download Jitsi, a free/open-source client capable of, among other things, telephony using ZRTP encryption.
  • Run it... or attempt to.  On later builds of OS X you may receive a message that Java 6 is required.  Well, I have Java 7 installed and enabled (it's needed for some other software I use), but this didn't seem to be acceptable to Jitsi.  With some trepidation given the security issues surrounding Java recently, I accepted the download of the older version.  There was no progress indicator, but events seemed to proceed without issue (and frankly rather quickly-- I have my doubts that Java 6 was installed at all), and eventually I was able to load and run Jitsi.  The current, recommended version of Java 7 remains intact on my system and is still my default, per the version tester at java.com.
  • Now you need to set up Jitsi to use your ostel.co account.  This is totally undocumented, but what works is to open its Preference pane and add a SIP account, specifying YourUserName@ostel.co (again, note it's not .com) and inputting your ostel.co account password.  
  • Done.

Set-up should be similar for other apps.  The only prerequisites would seem to be (1) the ability to work with generic SIP connections and (2) ZRTP compatibility.  (Be sure to select your desired audio input and output in the Preferences-- Jitsi had selected AirPlay as my default, rather than my Mac's speakers or headphones, causing some momentary confusion for me.)


[DELIGHTED UPDATE: seems the free Linphone iPhone app supports ZRTP!  Once you have installed the app and set up a username at ostel.co, just go to the app's settings and input your ostel.co username (minus the "@ostel.co" part), then your password, then "ostel.co" for the domain.  Then, in the Network settings, select Media Encryption and tick ZRTP.  Done!  This app even seems to support encrypted video.]

Now you can enjoy secure calls... or (let's have our eyes open about such things) allegedly secure calls.  Also keep in mind that the use of encryption technologies including email encryption and Tor (if detected) can spotlight you for special scrutiny and indefinite retention of your emails and other data, even if you are a U.S. citizen.

Audio quality in my testing has been excellent, clear and crisp and without echo.

08 June 2013

What PRISM may be... and means

London's Guardian and the Washington Post have published reports, based on leaked slides from a
Slide 4 presents a timeline.
Pay attention to the timeline.
National Security Agency PowerPoint of breathtakingly eye-searing design, alleging that the US Federal government monitors virtually all digital communications including VoIP, email, chat, file transfers and social networking.

The government has admitted to the general outline of all this, though it protests that many details are wrong.  That it has come to this should surprise no one familiar with current events and the unconstrained growth of the state.

Importantly, the original Guardian report noted that monitoring agencies could practically view one's typing in real-time.

The eruption of outrage was immediate, with most commentators taking literally the statement "collection directly from the servers" which appeared on the latest slide to be revealed, again by the Guardian, the "FAA702 Operations" slide.

Company spokesmen quickly denied the reports, first with brief, cautious statements remarkable for their similarity, and subsequently with broadened and less equivocal denials.  Meanwhile the sheer scale and intrusiveness that would be required to access these complex services "directly from the servers" is mind-boggling; the practicalities of mounting such an effort in so many technically diverse sites without a prior leak is hard to imagine.

The newly released "FAA702 Operations" slide
features the "directly from the servers" comment.
So let's just say those cranky paranoiac conspiracy theorists are looking mighty sage at this moment.  We'll learn more as time goes on.  However, for now most analyses hinge on the "directly from servers" notion and ignore other aspects of the slides which may point to plausible technical explanations of what's going on ...and suggest how one can protect one's communications.

A focus on data in-transit

The second of the four slides originally published by the Guardian notes, "Much of the world's communications flow [sic] through the U.S."  And the newly released FAA702 Operations slide speaks of collection from cables and equipment.  Putting the two together suggests that the eavesdropping infrastructure is in place at the trunk and/or ISP level.  This would hardly be news, as such monitoring is familiar from the evergreen ECHELON and Carnivore programs of the '90s, not to mention the fabled Room 641A.

Slide 2 of the original set.
The problem with eavesdropping is that much of the traffic today is encrypted.  Besides corporate VPNs and https web services, other alphabet-soup encryption protocols cloak connections between user and server, for example the TLS transit-encryption offered by some email services.  But--and this is important vs. Slide 4's timeline--transit encryption is a fairly recent option for consumer email.

Conventionally, data sent via encrypted transport cannot readily be eavesdropped.  Two problems, though: they only encrypt from user to server; from there on there may be no encryption.  Encryption between servers is rarer.  Furthermore, some encryption is better than others.  PPTP VPNs, for example, are more readily compromised than some others (though as I've argued elsewhere PPTP is adequate for many uses).  Also note that when you send an email, its recipients are always exposed to your email service provider and to any eavesdropper, unless your email service and your recipient's service are among the minority that will encrypt server-to-server connections, and then only for that hop in the chain.


Meanwhile, there is a compelling hint in Slide 4 that encrypted transport is not the roadblock it once was, at least to the NSA.  Note the progression of PRISM "participants," from 2007 to the present.  Now compare:




And so on.  The compelling thing about this observation is the possibility that Slide 4 represents a progression of low-hanging fruit, as the chronology lines up.  In each case there was an extended period between "participation" in PRISM and implementation of encryption.  This would give an eavesdropper ample time to optimize parsing schemes for a service's formats, patterns and protocols before having to deal with encryption.

This notion is supported by the fact that as recently as April, Apple's transport encryption scheme was reported as uncrackable by the government.  But that report was based on a leaked document from the Drug Enforcement Agency, which resides many steps down from NSA in the surveillance-technology totem-pole.  It's entirely possible that the DEA had not gotten the memo in April that the NSA had cracked Apple's encryption just last October as the latest in a rollout of that elite agency's decryption capability going back several years.

Also, note that most commercial transit encryption is based on encryption keys managed and secured by Certificate Authorities (CAs), firms specializing in creating, storing and serving authentication credentials that uniquely identify the participants in a secure transaction.  (Some large companies run their own CA, including Apple.)  But successful break-ins of Certificate Authorities have occurred with startling regularity in recent years; a Google search for certificate authority hacked yields tens of thousands of hits.  A sophisticated state actor possessing a CA's identity, keys or tools for generating them can eavesdrop on communications secured by the hacked authority's services.  Hence, one interpretation of the PRISM revelations is that they may indicate the ongoing cavitation of the CA-based trust chain.

[UPDATE: A new article in the Huffington Post describes the communications between whistleblower Snowden and journalist Greenwald: "Snowden only wanted to communicate securely using PGP encryption…"  Now, if Snowden is what he says he is and knows what he says he knows, that's a hell of an endorsement of PGP.  And more importantly, it indicates that the NSA does not have the ability to decrypt by brute-force.  So Snowden's reported preference--together with Slide 4's $20M budget number--even more strongly indicates a CA-spoofing approach as the likeliest explanation of the "as-you-type" claim.]

[UPDATE: A report by CNN, quotes further claims by Snowden, including "targeting fat data pipes that push immense amounts of data around the Internet... We hack network backbones -- like huge Internet routers, basically -- that give us access to the communications of hundreds of thousands of computers without having to hack every single one."  If true, breaking the encryption of such massive amounts of data can only be achieved by possession of spoofed or purloined CA credentials.  No known technology exists which would allow it otherwise, especially if costs are anywhere near the Slide 4 number.]

[UPDATE: The Electronic Frontier Foundation has published a marvelous and timely article, "How secure is HTTPS today? How often is it attacked?"  Money quote:
In short: there are a lot of ways to break HTTPS/TLS/SSL today, even when websites do everything right. As currently implemented, the Web's security protocols may be good enough to protect against attackers with limited time and motivation, but they are inadequate for a world in which geopolitical and business contests are increasingly being played out through attacks against the security of computer systems.
#1 on their list of vulnerabilities: "Break into any Certificate Authority (or compromise the web applications that feed into it). As we learned from the SSL Observatory project, there are 600+ Certificate Authorities that your browser will trust; the attacker only needs to find one of those 600 that she is capable of breaking into. This has been happening with catastrophic results."

The rest is essential reading, too.  Read the whole thing.]

The "As-You-Type" claim is a special concern

Webmail services help prevent loss of your work in the event of a disconnect or crash by frequently storing your draft on their server as you compose it.  This blog post, for example, has been saved to Blogger's server automatically many dozens of times as I've worked on it.  Had I typed something incendiary and intemperate about some politician or bureaucrat, that would have been stored as well-- and potentially monitored and inspected if my phrasing (or integrated profile) contained certain keywords or triggers.

This means cloud-based services of a wide variety have the capability of capturing and potentially monitoring your evolving thoughts and phrasing, even if you think better of them before committing the "Send" or "Publish" button.  So, it's bad enough that what you email and say is monitor-able... what you think is also.

Arguments

Perhaps PRISM is just an ordinary court-ordered data dump.  Verizon showed that those court orders can cast a wide net.  Counter-argument: Insufficient to explain "as you type" surveillance of the alleged sweeping extent, assuming that's true.  But maybe the as-you-type capability is part of the "Upstream" segment of the FAA702 slide rather than the PRISM segment.

Perhaps PRISM really does represent monitoring operations or back-doors at the servers of Google, Apple, Facebook, Microsoft, etc.  Counter-argument: These are highly heterogeneous computing environments.  Insertion of monitoring equipment or back-doors would be a massive undertaking and specific to each provider, involving their top engineering talent.  Hard to imagine how this could be feasible, especially for the $20 million annual budget in Slide 4.  On the other hand, the information flowing into and out of those servers, decrypted, is standards-compliant HTML and so forth-- eminently monitorable.

Perhaps the companies are lying.  Their statements were too similar, too scripted.  Counter-argument: Lawyers and executives tend to phrase things with precision, and the statements issued by company spokesmen reeked of lawyerly parsing and executive tip-toeing.  Spokesmen and CEOs would naturally have little interest in their companies' cooperation with occasional court orders, though they'd know they occur.  That's sufficient to explain the initial denials.  In fact, corner a Zuckerberg, Page or Cook on any controversial issue, and you'll get cautious phrasing like that.  It doesn't necessarily indicate collusion with the Feds nor anything to hide.  On the other hand, the creepy collection, correlation and wholesaling of user information is the foundation of the business models of several companies on the list.  But that doesn't provide as-you-type surveillance.

Perhaps PRISM represents an unfolding decryption capability based on Carnivore's progeny.  This, I think, is the conjecture most in keeping with the published reports to date, the as-you-type claim, the $20 million budget number, and Occam's Razor.  It requires only a generous interpretation of Slide 2's "directly from the servers": if one assumes that can mean directly from the pipes supplying the servers then the companies' broadening denials begin to make sense.  Even the Slide 4 timeline makes sense.

Law-abiding citizens have nothing to worry about.  This all just benefits terrorists and child-porn freaks.  Counter-argument: If you feel like bcc'ing Eric Holder on every email you send, be my guest.  Go ahead, set up your phone as a permanent party line with the NSA.  Think of a politician or bureaucrat you really loathe and share your desktop with them 24/7.  ...It is untrue that only creeps, paranoiacs and enemies of the state should be uncomfortable with the cataclysmic loss of privacy that PRISM may represent.  And here's a thought: if the US can do it, what if other countries can?  Fine, say you trust Barack Obama and the entire Federal edifice; do you also trust Xi Jinping?  Vladimir Putin?

Lots of the hoo-hah is about metadata.  At least the government isn't listening into your conversations.  Counter-argument: If you use any digital communications channel such as a cell phone or VoIP, conversations are among the most readily monitorable types of data on the list in the NSA slides, enjoying weak encryption if any.  Besides, the metadata--collected over time and correlated with that of your contacts and your interests--paints a very detailed picture of you.  It's the reason why the social networks are so highly valued.

What to do

President Obama defends the PRISM practices and warns that its disclosure will drive the bad guys underground.  That's a clue that it is still possible to hide.

First, although the trust chain for conventional commercial encryption may be irretrievably broken by now, it's still very much worthwhile to use https, ssl, tls and other transport encryption tools.  They are still effective against eavesdropping by all but the most sophisticated eavesdroppers, at least between your computer and your service provider.  After that first node, however, there are no guarantees.

Beyond that, encrypting your files and message contents using private encryption techniques (non-CA-based) would seem, from Obama's comment, to still be a way of cloaking your communications from inspection by anyone.  It seems likely that brute-force decryption remains elusive, especially for real-time monitoring.  (Certainly then-Sen. Biden must have had a reason for inserting identical anti-encryption wording in two unrelated bills.)

Among my suggestions --and believe me, the bad guys already know about these:

  • TrueCrypt is a free/open-source tool for encrypting files in various ways. 
  • GPGtools.org makes a fabulous plug-in for the OS X's mail.app that makes it easy to send and receive emails signed and encrypted privately, without reliance on Certificate Authorities.  It's free and open-source... I've donated, and recommend you do too.
  • GPG4Win offers something similar for Windows users.
  • FileVault2 is a whole-disk encryption technology that encrypts your Mac's entire hard disk with virtually no noticeable performance hit.  It secures your machine whenever it's locked or turned off, so that a thief, spy or Evil Hotel Maid is unlikely to get anything useful off of it.  It's installed on recent versions of OS X and just a Preference Pane check-box away from activation.
  • CryptoCat is an easy-to-use secure messaging tool, free and open-source, that supports a wide variety of computers and operating systems and can also be accessed in browsers.
  • Tor is an anonymized Internet connection that, used properly, obfuscates your location and cloaks what you're doing on it from your ISP on to whatever service you're accessing.  (Just, don't in the fullness of your fervor allow your machine to be a Tor exit node... the service is popular with assorted creeps and bad-guys, and you will be their traceable identity if you do that.)  [UPDATE: In reply to my question on their "Tor vs. PRISM" blog post, Tor developers noted, "Tor does not rely on any CAs. Every node generates its own keys and directory authorities are hard coded into the application. If you are looking for an introduction to the way Tor works there are several videos on YouTube."]
  • Wickr is a secure communications app for iOS and, soon, Android that features self-destructing messages and other privacy tools for communicating with other Wickr users.  (My username: sjwickr)
  • Silent Circle is a secure communications platform that includes encrypted VoIP for talking, emailing and messaging other Silent Circle users.  From Phil Zimmermann, inventor of the PGP encryption algorithm (and the target of Biden's legislative trickery).
  • Liberté Linux is a specialized version of Linux which deeply integrates encryption and Tor networking (for example replacing the conventional browser with one that only uses Tor) and which replaces conventional email with secure "cables" to other Liberté users (I'm hxwua6y464h4cpuq5oscyq3bvxpxxgbu@cpundtimj5g6twt2.onion ...for now).  Liberté can be run in a virtual machine or booted from a CD or USB stick and must be left running in order to receive cables.

Ultimately...

My recent essay, Free vs. Freeing, touched on the central issue of all this: as we utilize free services provided by friendly companies, the costs are often unacknowledged.  Now, I speak as a guy writing on Blogger's Google-owned service... which is not a problem, as I'm aware that as I've pecked at this post, my evolving thoughts have been uploaded, my profile is correlated and marketed, and my ultimate message is noted.  But for other services, I'm among the cognoscenti who will happily spin up a service on my own machines, who knows to implement PGP to help ensure the privacy of email conversations,  and so on.  So, certainly, take advantage of the products and services mentioned above. But take this as a call to educate yourself: on what's alleged, what's going on or could be, on the technologies involved and how they've broken down, on how to reduce your reliance on them, and most of all how it has come to this.  We may, as some have stated, be beyond the point where the democratic process can influence matters.  There's only one way to find out.

27 May 2013

Free vs. Freeing

This essay was originally posted on Patricia Seybold's Customers.com.



Drive through the green hills of the Virginia horse country: dotting the rolling landscape are lavish
estates of the truly rich, distant stone monuments to old money overlooking countless acres of beauty and protection. Nearer the cities lie gated communities of the merely well-off, cloisters of fine homes and upscale condominiums onto whose streets only the authorized are admitted by uniformed guards. Then come the jumbled neighborhoods of the common, for whom horses are perhaps something to bet on and cheer if they’re of any consequence at all, the everyday business of existence being more at stake each day.

The stratification has evolved naturally, with the wealthy seeking high and isolated ground of their own, the accomplished erecting pens for themselves, and the rest left to strive as well as they can as they bump and clash their way through their weeks and days, doing what’s obligated and taking what’s offered. Humans have organized themselves in similar ways for centuries: feudal fiefdoms, the beau monde, tribal civilizations, even academic societies naturally organize themselves in this fashion.

It’s nothing new.


The term personal computer is now precisely three decades old, but only recently have computing devices begun to truly shade within the penumbra of the person. A beige box on a desk was, in retrospect, hardly personal. A location-aware computing and communications device in one’s pocket is more so—always on, sense-enabled, and always connected to the new compute, data, and social resources of the world—and it has begun to influence, define, and modify personhood. Wearable computers are next: after that lies conjecture, but it is certain that devices will fuse ever closer to the essence of the person even as their resources and mechanisms evanesce to the cloud.

It’s unremarked, but of little wonder, then, that a similar stratification is emerging among these more-truly-personal devices. From the roiling primordial bog of silicon and copper that incubated technology for 30 years have emerged devices made increasingly in our own image: they help us see, help us remember, help us chatter and enjoy, help us earn and retain wealth—both the old kind, denominated in numbers and influence, and a new kind denominated in gnostic power.


For those affluent in this new way, there will be self-contained estates, separate and secure. For them, information is something maintained aloof and stoic and distant, and, most of all, detached. These elite of the new elites will build their own unapproachable stone monuments to their uncommon mastery of the wisdom of this age. They will loft their own clouds, because they can.

For those merely well-off in this new way, there will be gated and protected neighborhoods, their assets secured by paid patrols and uniformed guardians. For these burghers of the new era, security is something hired; privacy is a matter of dues and subscriptions; trust a matter of fealty.

For the common—those who participate without influence, who build without architecting, who use without grasping, who exalt but don’t know—the new age offers bounties, but wealth of the new sort is not theirs. Instead, for them lie days of labor leavened by circuses, their comings and goings predictable and, moreover, predicted, by their overseers, who ladle out a benign daily porridge without obvious cost.

Democracy, exult the common: behold the flattening; let no one hunger for bits and bytes and presence, and all for free.

Order, smile the bourgeoisie, secure in their pens, overwatched by guardians.

Liberty, sigh the lords, separate and free.

27 February 2013

On Marissa Mayer's New No-Remote-Work Policy


Has Mayer explained what's going on here?  

I'm not seeing it, not in the original reports (in which Yahoo specifically declined comment) or in anything subsequent.

I can go either way on her decision depending on what her objective is for making it.  For now, that's tabula rasa.  This article is a good example: it's one author viewing the decision through the lens of a working mom.  Okay: so the article reflects more the world-view and priorities of that particular author.  All the commentaries do, in fact, because what they're missing is the world-view and priorities of one Marissa Mayer.

Sure, Yahoo needed a shaking up.  A culture change.  A refocusing and a reduction in both force and in breadth of endeavors.  If a foundation of business is "find a need and fill it," it's not clear how the latter-day Yahoo is doing either.  Mayer's Job One is to fix that.  Okay, so how does this new policy fit in?

I'm a huge fan of the Five Whys technique.  So far the why-ometer is stuck at zero.

IMHO, we (and the pundits) have insufficient data for analyzing this move, much less criticizing it.  

But Mayer and Yahoo can be criticized for not getting ahead of this story.  From page 202 of Scott's Big Book of Pithy Pronouncements, Milton's Law states: "In the absence of information, people will naturally assume the worst."  Insofar as that's in play, it's potentially damaging and difficult to control.  In that regard, I'm not impressed.

30 October 2012

On using VPNs, Proxies and VoIP from behind a restrictive firewall

I framed my posts on setting up one's own secure, encrypted Internet access via a Raspberry Pi with the notion of accessing one's Netflix account from outside the U.S.  That's certainly an understandable desire, and either of the solutions I've documented so far (ssh proxy and pptp VPN) will work well for that purpose, assuming your hotel Internet connection provides sufficient basic throughput.

But there is another potential usage: travel through a region in the world known for suppressing or monitoring individual Internet activities.  For example, in one country I've visited whose national firewall is well-known, all blog engines I tried were blocked (blogger.com, wordpress.com), as were all user-generated video sites (YouTube, Vimeo) and all social-media sites (Facebook, Twitter).  Similarly many political and commentary sites were blocked, especially those with what Americans would regard as conservative or libertarian viewpoints.  Most news sites were allowed through but in localized form with filtered content.

In such cases, it may be helpful to have one's Raspberry Pi running 24/7 on your home broadband connection, serving up the several work-arounds I've documented:

  1. An encrypted pptp VPN suitable for any client (Mac, Windows, iOS...);
  2. A ssh proxy suitable for laptops, and
  3. A php anonymous web proxy I haven't gotten around to blogging about yet.

(Just be very sure you're familiar with your host's rules and laws... see below.)

Here in the U.S., I've found each of these approaches to have pluses and minuses:

(1), the pptp VPN approach, has generally been preferable for my usage since all platforms are supported, all traffic can be encrypted, your IP address cloaked, and blockage of things like VoIP services is circumvented.  This approach requires no downloaded client or jailbreaking, but it utilizes the standard pptp IP port, which some localities block (and, annoyingly, it seems alternate ports cannot be specified in the built-in VPN client in Windows, OS X, iOS or even Linux).  Note, however, that pptp VPNs utilize the ms-chap v2 encryption algorithm, which some commenters here have pointed out is potentially hackable, though with considerable effort.  Using a long, highly randomized password can help on that point.

(2), the ssh proxy, is immune to the port-blockage problem because I've documented a way to use the port ordinarily used for https web pages, which presumably will probably never be blocked.  All your traffic is encrypted, your IP address is cloaked, and blockage of things like VoIP activity is circumvented.  No downloaded client software is needed.  But, it's suitable for laptops only.

(3) is a familiar anonymous web proxy, so it's just a web page and its port will never be blocked except in severe cases of national Internet shutdowns.  It requires no downloaded client software.  But only your web traffic is encrypted/cloaked.  Things like VoIP-port blockage can't be gotten-around using this approach.

Of course, there are also commercial services like Cloak (www.getcloak.com) and TorVPN (www.torvpn.com) and any number of anonymous web proxies available, both free and paid.  However, commercial services' IP addresses or URLs are sometimes blocked by institutions and countries.  Running your own service on your home broadband connection should avoid this issue if you keep your usage moderate and your mouth shut, and if you avoid the temptation of checking your cloaked IP address using services such as http://whatismyipaddress.com which can record such inquiries and thereby database them as likely coming from curious users of VPNs or proxies.

When it comes to countries with restrictive Internet policies and national firewalls, you will still probably find the pptp port accessible through your hotel connection.  Most host countries want to encourage commerce and more concerned about suppressing individual activities than preventing businessmen from securely contacting their corporate resources.  Consequently, the classical pptp VPN may be open, although known non-corporate VPN and proxy services may be blocked on a URL or IP address basis.

VoIP

Making calls when traveling in foreign countries can cost a fortune using conventional cell-phone roaming minutes.  You may find that even despite the crappy Internet connection in your hotel, the standard VoIP port may remain unblocked.  If so, and if it's legal where you are, you can try making a test call using your smartphone's VoIP app-- my favored iPhone/Android VoIP app, 3CXPhone, has worked beautifully for me in many such circumstances.  If so, the beleaguered router in your hotel has an effective Quality-of-Service (QoS) engine that prioritizes your VoIP traffic well enough to work for you.  Or, if the VoIP port is blocked (or if you'd prefer your conversations be encrypted, which normal VoIP is not, or if you'd like your use of VoIP to be hidden altogether), running your connection over your Raspberry Pi's pptp VPN might work, but the additional latency might or might not be a problem.  The new Silent Circle app might also be of interest if security and privacy of your conversations is desired; ditto running Liberte Linux or some other anonymized operating system.  Just keep in mind the legal points noted below.

A couple of important points


1) Technical

There are many potential bottlenecks in a cloaked or proxied connection.  Your hotel Internet connection is one, and nowadays it's almost a given that it will be pretty lousy.  But your home broadband connection is potentially another (especially the upstream bit-rate, which is usually much lower than downstream).  And the current Raspberry Pi implements its Ethernet port as a USB 2.0 device, so its throughput is limited to USB 2.0 speeds (theoretically 480 Mbit/sec but, in practice, less).  Keep in mind that every bit of VPN'd or proxied traffic must flow through your Raspberry Pi twice: first via your broadband downlink from the site our service you're visiting, and then via its uplink to you.  Plus, routing your Internet traffic through your Raspberry Pi from afar obviously adds latency.  All these limitations have an additive effect.

Also keep in mind that some localities will monitor traffic bit-patterns and flag unusual usage.  For example, if you're running a ssh proxy over the https port as I've documented, your host might notice that your usage doesn't match ordinary webpage-visiting behavior.

Your home ISP might similarly detect your usage (especially if it's heavy) and declare your online employment of the Raspberry Pi to be in violation of terms of service which prohibit running servers.

2) Legal

Accessing forbidden websites and services, utilizing a VPN or other forms of encryption, using a proxy, communicating via VoIP, etc., may be illegal in some countries, and many such activities can get you in trouble on college campuses too, not to mention the dim view employers take of employees accessing blocked services via whatever tricks. (It can even be cause for immediate termination.)

Please be mindful of your host's rules and laws-- this is your responsibility and obligation, and (not being a lawyer) I can offer no advice or counsel on the matter.  As far as countries go, while it's true that many are more concerned about keeping their citizens in line rather than crimping visitors' style, that's a risky assumption to make.  Be informed, and utilize tools such as these at your own risk and with your eyes wide open.


28 August 2012

How to set up a real, encrypted VPN through your Raspberry Pi

Well isn't it always this way... the very day after I post on how to use the Raspberry Pi as a secure Internet proxy by working around a missing element in its variant of Linux, that missing element becomes available in the stock OS!

Here's how it went.  On a whim, even though I'd just given my Raspi a full software update just two days ago when I made that earlier post, I repeated the process again today:

sudo apt-get update
sudo apt-get upgrade

...and lo, there were some important packages that updated.  Sniffing further, I attempted the first step of the installation process for installing a "real" PPTP VPN onto Debian Linux:

sudo modprobe ppp-compress-18 && echo success

No error was reported!  The formerly-missing MPPE module has been added to the kernel.

Well now.  This poses the tantalizing possibility of setting up a real, Point To Point Protocol (PPTP) Virtual Private Network using the Raspberry Pi as a gateway.

A VPN strategy for every situation

Among the highly non-trivial benefits of the PPTP VPN versus the ssh proxy tunnel I documented previously include compatibility with iPhones, iPads and other mobile devices which might not offer ssh port forwarding capabilities in their operating systems.  That was the basic trick of the ssh proxy tunnel.

On the other hand, PPTP VPNs utilize the GRE 47 protocol which is some routers find indigestible while others can accommodate only one GRE 47 connection at a time and will block all others-- a recipe for trouble in hotels and public hotspots.  By comparison, the ssh proxy trick I documented--which leveraged the https or other common port for the ssh proxy tunnel--will be more likely to always work as you travel, at least for your laptops.  Frankly, at this point I have both the ssh proxy tunnel and the PPTP VPN set up on my Raspberry Pi, and I might as well leave it that way so I'm covered for just about any circumstances.

Here's how


There are many tutorials available for setting up the PPTP server daemon (pptpd) on a generic Debian Linux machine.  However, I've found that the Raspberry Pi presents a few quirks and needs its own instructions.  The following steps worked for me and resulted in a robust VPN that has held up to my usage so far-- this blog post was constructed entirely while connected via my Raspberry Pi's new PPTP VPN.

  1. Open port 1723 on your router, pointing it to your Raspberry Pi's IP address on your LAN. 
  2. Your Raspberry Pi should have a static IP address on your LAN.  Good instructions for that are here.
  3. Next, if your home ISP does not give you a static IP address on the Internet, you'll need to set up an account with a dynamic DNS (DDNS) service.  This will give you a URL which will always point to your router.  My D-Link DIR-655 router (a truly excellent router, by the way) earns me a free DDNS account on D-Link's service; there are plenty of alternatives.  In D-Link's case, the url will look like [username].dlinkddns.com.  UPDATE: My trusty DIR-655 died, and the units currently being sold now are totally different.  I switched to an Apple Time Capsule, which necessitated a new dynamic DNS provider.  I chose DynDNS.org... you get one free host name for trying their 14-day "pro" account (which you can cancel, keeping the host name, though their services are powerful and quite cost-effective for what you get).  
  4. Log into your Raspberry Pi either via its local console or via ssh.  
  5. Issue sudo apt-get install pptpd
  6. Issue sudo nano /etc/pptpd.conf --this will start a simple text editor on your Raspi.  Note that most lines are comments and are commented-out with a "#" at the beginning.  Scroll down until you find the lines which set localip and remoteip.
  7. Set localip to your Raspberry Pi's IP address.  For me, that line becomes localip 192.168.0.202.
  8. Set remoteip to encompass a small block of IP addresses on your LAN that will be made available to your remote client(s).  For me, that line became localip 192.168.0.240-255 ...there are various rules for how that block can be constructed; use the format shown here or it might not work.  
  9. Hit ctrl-X and save the file.
  10. Now issue nano /etc/resolv.conf and make a note of the nameserver identified in this file --for me, and I'd bet most other folks, it's the LAN address of my router, 192.168.0.1.  Hit ctrl-X to close the editor.
  11. Issue sudo nano /etc/ppp/pptpd-options and scroll down until you find references that set ms-wins and ms-dns.  You want to set thise to the nameserver address you just noted.  For me, these lines became ms-wins 192.168.0.1 and ms-dns 192.168.0.1 respectively.  Hit ctrl-X and save the file.  This completes the basic IP setup for your new VPN.
  12. Issue sudo nano /etc/ppp/chap-secrets and scroll down to an empty line.  Here is where you will specify your users who can use your VPN.  For a user named Ralph with a password of SuperSecret123, the line would simply be Ralph pptpd SuperSecret123 *  --the asterisk at the end is important as it specifies that Ralph can tunnel in from any IP address.  Repeat with additional lines to specify other users you want to allow to tunnel in via your Raspberry Pi.  Then hit ctrl-X and save the file.
  13. Issue sudo nano /proc/sys/net/ipv4/ip_forward  ...see the zero?  Change it to a 1.  This tells your PPTP daemon to forward remote clients to the Internet.  Hit ctrl-X to save the file and exit the editor.
  14. Issue sudo nano /etc/sysctl.conf and scroll down until you see the commented-out line that states net.ipv4.ip_forward=1  ...uncomment this line (remove the"#").  This will tell your Raspberry Pi to always allow remote clients to access the Internet via their tunneled connection.
  15. You're done!  Reboot your Raspberry Pi.
  16. While you're waiting for it to sort itself out, you can set up a VPN connection on your traveling (client) machine.  On the Mac, go to System Preferences | Network, click on the padlock and authenticate as an administrator user, Click the "+" sign and select "VPN" from the pull-down menu.  Give this new VPN a name.  Voila a new, unconfigured VPN connection will pop into your network-connections options.  With this selected, type in your dynamic DNS address for your Raspberry Pi (e.g., YourUserName.DynDNS.org).  In the Account Name field, put the username you specified in step 12 ("Ralph").  Click the Authentication Settings and specify the password from step 12 ("SuperSecret123").  Click the Advanced button, and be sure to checkmark the option to route all your Internet traffic through the VPN.





You're done!  (Setting it up on an iPhone or iPad is even easier.)  

You should be able to connect now, and all your Internet traffic will be encrypted and funneled through your Raspberry Pi from wherever you are... or at least from wherever VPN connections are tolerated.  For other places, consider the ssh proxy tunnel I wrote about before.

26 August 2012

How to use a Raspberry Pi as a secure Web gateway from anywhere


UPDATE: The necessary modules for supporting a "real" PPTP VPN have been added to the stock kernel.  While the following methodology offers benefits in many situations, you might want to consider this new post on the topic, or set things up both ways.

----

Being a geek, I was the first kid on my block to sign up to purchase a Raspberry Pi Model B, a $35 computer-on-a-card that's about the size of a pack of cigarettes.  In fact, since it comes without a case, I'm tempted to buy a pack of cigarettes, toss the coffin-nails and use the wrapper as an enclosure.  Maybe someday.

Anyway, this is a fully-fledged computer centered on an ARM-based processor that's a couple notches down in capability versus the CPU found in an iPhone or Android phone.  Nevertheless it is capable of running a variety of operating systems, and it benchmarks roughly equivalent to a typical i386 or Pentium machine of a few years' vintage.  Against that metric, the power efficiencies alone are amazing.  This thing runs off a cell phone charger.

The Debian-based variant of Linux that the Raspberry Pi folks recommend as their standard OS now enables hardware acceleration which makes most operations nicely speedy.  It works quite well and, being Debian-based, has access to a huge array of free software.  I have a few projects in mind for this little pup and currently have it running the full LAMP webserver stack (Linux, Apache, MySQL, PHP) just for chuckles.  Despite all that, more than 180MB of its 256MB of RAM is unused.

There will be more to come for this device.  First up: sometimes in my overseas travels I find I can't access my US-based services like Netflix.  Connecting via a hotel WiFi network when overseas gives me a non-US IP address which Netflix detects, and since Netflix's licensing agreements with studios and TV networks don't cover overseas customers, it will refuse to serve up content even though I have an account in good standing back home in the U.S.  Blockage of other Internet-based functionalities also sometimes occurs for other reasons-- for example, VoIP traffic is sometimes blocked, either purposefully or through poorly-considered blanket policies which boil down to "We shall allow common things like web browsing and block all else."

How nice it would be, then, to run a VPN or similar private pipe through the Raspi.  The Raspi's IP address would then be the face of my connection to Netflix and everything else.  Theoretically, I could activate that whenever I needed a US connection or found my connection to some service blocked for whatever reason.

Unfortunately, the Raspi's current recommended Linux build contains a stripped-down kernel that does not support certain features needed for establishing a common encrypted PPTP VPN connection.  Specifically, the kernel lacks MPPE support, and the Raspi will spit an error in the first step of procedures like the one documented here.  Some folks have compiled custom kernels--it's not too difficult--but for various reasons I want to keep my kernel stock-standard.  Perhaps someday the stock kernel will include MPPE support-- it seems everything else needed is present in the stock build and its repositories.

But there's a simple alternative which works well and is almost as capable and easy to use, and that is to use the port-forwarding capability of the ssh server built into Linux to set up the Raspi as a proxy for remote machines.

Here's how



  • First, the ssh server must be active on your Raspberry Pi.  Most folks will have enabled this at setup time.  If not, poster "Abishur" gives the details here.
  • Set your Raspi with a static IP address on your LAN.
  • Next, if your home ISP does not give you a static IP address on the Internet, you'll need to set up an account with a dynamic DNS (DDNS) service.  This will give you a URL which will always point to your router.  My D-Link DIR-655 router (a truly excellent router, by the way) earns me a free DDNS account on D-Link's service; there are plenty of alternatives.  In D-Link's case, the url will look like [username].dlinkddns.com.  
  • You'll need to open your router's ssh port and forward it to your Raspi's IP address on your LAN.
  • On your Mac, bring up the System Preferences | Network preference pane.  Click the padlock and authenticate as an administrator if necessary.  In the Location menu at the top of the preference pane, select Edit Locations.  Highlight the connection-location you normally use for attaching to networks when you travel, click the "gear" icon, and select Duplicate Location.  Give this duplicate a name such as "Normal Connection over ssh via Raspberry Pi".  Click Done.  Now, select the duplicate location and click the Advanced button, then the Proxies tab.  Checkmark the SOCKS protocol and specify "localhost" and port 8080 ...actually, the port doesn't much matter (just be sure to specify the same port in the next step), and 8080 is innocuous.   (Click to enlarge):



Click OK and then Apply.

You'll find your Mac will update its connection to whatever WiFi or Ethernet service it was on before, but Internet traffic won't flow quite yet.  Next, open a Terminal window.  If you've been working in a non-privileged standard user account, type "login [administrator account name]" and enter the password at the prompt.  Then--and here you need to be a bit cautious since you're futzing with your Mac's system files--type "sudo nano /etc/ssh_config"

This will start the Nano text editor and load in your Mac's ssh defaults.  Scroll down to just above the "Host *" line and insert the following:

Host webproxy
  HostName [your dynamic dns url]
  User [your username on your Raspberry Pi]
  DynamicForward 8080
  Compression yes


Type ctrl-X and say yes to the prompt to overwrite the current copy of ssh_config.

Close the terminal window.  Setup is now complete.

Using your secure tunnel connection


Now you're set.  On any given day when you find an Internet service blocked:


  1. In the System Preferences | Network preference pane, select the location you created with the ssh connection proxy via your Raspberry Pi.
  2. Open a terminal window, and simply type "ssh webproxy" and provide your Raspberry Pi user account password when prompted.  


You'll now have Internet!

...But don't close that terminal window.  What's happening now is that all TCP traffic to and from your computer is being routed through your encrypted ssh connection, which will be closed if you axe that window.

When you're done: switch back to normal connectivity by selecting your usual location in the System Preferences | Network preference pane.

Note that this approach is almost but not quite as functional as a nice PPTP VPN.  It is, however, pretty much limited to providing remote access just for personal computers.  Connecting via ssh is not well-supported by mobile devices, unfortunately.  For those, a proper VPN setup would be most beneficial.  Perhaps next time.  Also, it seems that while TCP traffic is routed, some other types of traffic may not be (which would seem to be why you can type "ssh webproxy" and log onto your Raspberry Pi when Internet isn't otherwise flowing yet after selecting the ssh proxy'd location in the preference pane.)  So even though TCP traffic is encrypted, don't go trading state secrets over this connection.

In my testing, using this ssh proxy approach has shown a negligible impact on Internet throughput versus my home's normal network connection, which is admittedly fairly entry-level.  If my hotel's Internet connection is good enough to support Netflix streaming in the first place, content streams just fine.  Latency increases a little, but it's pretty terrible to begin with on my home Internet service.  Note that all your remote traffic routes through the ssh port on your router, so if your remote usage would involve time-critical applications like VoIP, it might be a good idea to add that port to the router's Quality of Service (QoS) priority list.

Demo: We're Not In Kansas Anymore, Toto


With my Mac tethered to my iPhone, the handy WhatIsMyIPAddress.com maps my IP address as in Kansas:


By selecting my new ssh proxy "location" in the System Preferences | Network preference pane and typing "ssh webproxy" in a terminal window, now it appears I'm connected via my home ISP in California, where my Raspberry Pi resides... even though I'm still tethered to the iPhone:



One wrinkle...


You should consider the possibility that in your travels, access to the ssh default port of 22 might be blocked as well.  A good plan for that case is to make use of a port unlikely to be blocked and otherwise unused in your setup.  For me, although I'm playing with my Raspi as a tiny web server, it's not serving encrypted (https) pages.  So the https port 443 is not being used and is a great candidate for our pipeline's usage.  To use this:


  • Open port 443 on your router and forward it to your Raspberry Pi.
  • If you have Apache enabled on your Raspberry Pi, comment-out the "SSLEngine on" line in /etc/Apache2/sites-available/default-ssl:




  •  Then add port 443 to the listen-list in /etc/ssh/sshd_config on your Raspberry Pi:



Reboot your Raspi ("sudo reboot") and give it a couple minutes to sort itself out.  Henceforth, on your Mac, you can type "ssh -p 443 webproxy" to route your ssh connection over port 443, which all but the most uncooperative hotspots should leave unimpeded.


Incidentally, most of the above can be useful for figuring out how to do something similar on alternate platforms: a Windows remote client instead of a Mac, for example, or a generic Linux machine or something like a Mac Mini rather than a Raspberry Pi.  Of course, if you can use a fancier machine than a Raspberry Pi (or use an alternate or custom kernel in a Raspberry Pi), you can just set up a nice PPTP VPN on it.  If the ssh proxy approach is any indication, it should work just fine.