The Underlying Layer in Most 'Secure' Messaging Apps Might Not Be So Secure
"Basically: security as a plug-in does not work."
In the aftermath of last year's Snowden revelations, a bevy of secure messaging apps have been making the rounds. Their promises range from protection against eavesdropping signals intelligence agents to other hostile actors. But if the EFF's recent scorecard of encrypted apps is any indication, secure messaging remains a veritable Wild West. And some experts are suggesting that one of the most popular apps for secure messaging on the desktop is the digital equivalent of a leaky boat with too many holes to plug.
There's a good chance you've encountered libpurple, even if you don't know it by name. It's the common codebase upon which some of the most popular instant messaging clients, including Adium and Pidgin, are built. But just because something is popular doesn't necessarily mean it's secure. And security—or its lack thereof—is why a lot of people think libpurple should be replaced.
This isn't news to those in the security community. One researcher described libpurple to Motherboard as a perennial target for exploitation, burdened by what some perceive as an old, bloated codebase and cryptographic features that aren't part of libpurple's design, but merely layered on top. And while the perceived severity of libpurple's problems depend on who you talk to, there's a common refrain that surfaces regularly online—that it's time to replace Pidgin, Adium and similar apps with something else entirely.
Libpurple is the Swiss army knife of instant messaging, with 15 instant messaging apps in one
Libpurple has been in development since 1998. It was created so that, with just one app, users could chat with friends on multiple different instant messaging services at the same time. Put another way, libpurple is the Swiss army knife of instant messaging, with 15 instant messaging apps in one. Pidgin and Adium are really just user interface wrappers that are built on top.
One popular libpurple plug-in is called libotr, or Off-the-Record messaging, perhaps the most widely recommended method for secure messaging besides email with PGP (Pretty Good Privacy). OTR makes it easy for two people to have private, encrypted conversations over instant messaging.
It's a pretty smart piece of cryptography that ensures the person you're speaking with is who they say they are, and that during your conversation, messages cannot be forged. It also employs something called "perfect forward secrecy," which ensures that, even if an attacker were able to obtain the encryption keys to your conversation, they wouldn't be able to decrypt previously sent messages that might have been intercepted in the past.
Together, Adium, Pidgin and OTR are supposed to offer a robust, secure messaging experience across almost any instant messaging network. But in practice, some members of the security and cryptography community are worried that the two libraries, and the interplay between them, are vulnerable to exploitation—based primarily on the age, size, and style of their code.
Adium and Pidgin, for example, are often criticized as "complex feature-rich IM clients built to support as many (often crazy) protocols as possible with regular-to-minimum-to-zero attention to security with ON TOP a thin plug-in that makes a best-effort to wrap everything in a cryptography layer," wrote Filippo Valsorda in an email. Valsorda is a security engineer with the web company CloudFlare, who spoke to Motherboard personally, and not on behalf of the company.
"The result is that the [user interface] is not built to make secure choices smooth, or the default, the underlying client is easy to exploit, and it's super-easy to slip and send messages unencrypted without wanting [to] because the plug-in fails to cover some corner-case," he wrote.
Put another way, the most-recommended apps for secure messaging on the desktop are based on an old, sprawling codebase that was never designed with encryption built-in by default.
"Basically: security as a plug-in does not work," Valsorda wrote.
When encryption is available as a plug-in, it gives users a choice between being encrypted or not—and "not" is the default. Even if that plug-in is easy enable or install, there's still the possibility that someone will forget to turn it on. And that's not something you want to risk if you're living under threat of arrest within a repressive regime. It's not as intuitive as, say, an app where encryption is simply enabled by default. That's the approach that Open Whisper Systems has taken with its encrypted phone app Signal, and encrypted mobile messaging app TextSecure. You could hand it your grandparents and they'd be none the wiser. There's not much chance for them to mess things up.
But there's another problem, too. When your encryption code is separate from your chat code, you're widening the potential area for attack.
"The combination of libpurple and libotr—actually the combination between any chat client and libotr itself—that combination should scare people," said Thomas H. Ptacek, previously the founder of independent security research firm Matasano Security, and founder of a new firm called Starfighter, via phone.
Multiple people have reported that the developers working on libpurple have, historically, been slow to fix security vulnerabilities, of which there are apparently many. An email sent to Tomasz Wasilczyk, a Pidgin developer who has written about OTR on the project's blog, was not returned.
Other developers, including Valsorda, have expressed concern that libotr and libpurple are written in the programming language C, which isn't "memory safe"—in other words, subject to attack via the memory space that all apps share.
Just last week, John Hopkins University cryptographer and research professor Matthew Green bet Ptacek $1,000 that "a severe vulnerability is found in libotr" before November of next year.
Ptacek says he may already have lost his $1,000 bet with Green, and is currently investigating the veracity of some suggested flaws. However, he theorizes that there are likely fewer problems with OTR given the relative cryptographic expertise of its development team compared to libpurple, the code on which Adium and Pidgin are based. An email sent to University of Waterloo cryptographer professor Ian Goldberg, who is the lead developer of OTR, and currently on sabbatical, has not yet been returned.
While there are certainly alternatives to libpurple, replacements are harder to come by. TextSecure, for example, is a well-regarded secure messaging app, but it's only available for mobile devices, and is incompatible with XMPP and OTR. Cryptocat boasts an impressive, easily understandable user interface—a common critique of Adium, Pidgin and OTR—but is also incompatible with XMPP and OTR, and not without past concerns of its own.
There are at least two potential replacements to Pidgin and Adium. One is Gajim, which is written in Python (though it isn't much to look at, and does not encrypt messages by default), while the other is xmpp-client, a command line only interface with no user-friendly graphical interface. Neither has really caught on.
Valsorda says his ideal client would have a smaller attack surface than libpurple – "less features, less protocols, less checkboxes, less options, less code," he wrote. "It would be built from the ground up with security in mind, allowing only encrypted communications, easy to use right and impossible to use wrong, and finally written in a safer language, like Go."
Another option, which also has its supporters, is improving what we already have. Tor developer Jacob Applebaum has done extensive work on improving the libpurple code, and has worked with Ian Goldberg to improve OTR's integration with libpurple too (Applebaum, too, did not respond to an email from Motherboard).
Others have suggested releasing a minimal fork of Pidgin with just one instant messaging service supported, rather than 15—specifically, an instant messaging protocol called XMPP, upon which Gchat, Jabber and Facebook Chat are based. OTR would be enabled by default. Better still, others have suggested an XMPP client that doesn't involve libpurple at all.
"Nobody would be unhappy with a new implementation of XMPP," said Ptacek. "Something to replace libpurple, something designed from the ground up to be secure—that is a good idea."
Because ultimately, it's unclear to some whether libpurple can be fixed. "It's great that bugs are actively getting fixed in software that experts recommend activists to use," Micah Lee, technologist at The Intercept, wrote in a blog post last year, "but who knows how many more bugs haven't been reported to the developers and are actively in use compromising the computers of people who put in extra work to remain secure."
It may very well be time for something new—something that's easy to use, works with XMPP, and encrypts instant messages on the desktop by default. That could even be libpurple, if the code continues to improve. But until then, as imperfect as they may be, Adium, Pidgin and OTR are still the best we've got.