Security

Email insecurities

As the software development world continues to react to the Edward Snowden revelations about pervasive government surveillance, a lot of attention has been paid not just to hardening the various implementations of core Internet services against exploitation, but to what needs to be fixed in the core protocols as well. While there is clear room for improvement where web traffic is concerned—from the certificate authority system to SSL/TLS—there is far less agreement on what can be done with email. Some bold new projects have been announced, but it remains to be seen if replacing SMTP or IMAP can put a stop to the real threat posed by spying conducted by law enforcement agencies.

Lava down

Prior to August 8, 2013, Lavabit offered an encrypted email service that boasted of second-to-none privacy protection for its users. The cornerstone of that protection was that user data was securely stored to the point that not even Lavabit itself could decrypt and read any users' stored messages. In July, however, news broke that Edward Snowden was a user of the service, and the US government got a search warrant requiring Lavabit to hand over its private SSL keys so that investigators could examine the account of an unnamed customer—presumably Snowden. Lavabit objected to the warrant, arguing that surrendering the keys would expose not just the account named in the request, but all of its other customers, too. The courts did not regard that complaint as particularly persuasive, and ordered Lavabit to surrender the keys immediately or face a fine of $5,000 per day. On August 8, the company turned over the keys, and shut down the email service.

Because Lavabit stored customer messages in encrypted form on its servers, the supposition of many was that the SSL keys could only be used to tap connections between clients and servers. Thus, by shutting down the service, Lavabit was making it impossible for the government to eavesdrop on the SSL connections, since none were taking place.

Although this string of incidents was particularly high-profile, it was not the only one of its kind. On August 9, another encrypted email service provider, Silent Circle, shut down its service as well, citing the Lavabit case as the cause. Silent Circle then proceeded to erase its private keys, even though they had not been requested by the government.

The service shutdowns might be regarded as nothing but two isolated closures (albeit casualties of government interference), except that Lavabit and Silent Circle subsequently announced the Dark Mail Alliance, a joint project with the stated mission of bringing "the world our unique end-to-end encrypted protocol and architecture that is the 'next-generation' of private and secure email." Dark Mail was announced on October 30, and the announcement says that the group will make both the system architecture and the protocol open source. But, other than that (certainly admirable) goal, no visible work has emerged from the project yet.

The dark side

Despite the general agreement that email needs a major overhaul—and that PGP-style encryption is probably not going to catch on in a big way—not everyone finds the approach taken by Lavabit worth following. On his blog, Moxie Marlinspike posted an in-depth critique of Lavabit's design, noting in particular that the company's claim that customer email could not be read by Lavabit administrators seemed to be entirely untrue. Lavabit did store messages in encrypted form on the server side, but it also stored the decryption key and that key's password on the server.

In fact, Marlinspike noted, the government's warrant requesting Lavabit's SSL keys suggests that the government was more interested in decrypting historical SSL traffic that it had collected, rather than tapping new connections. If true, of course, then Lavabit's shutdown means the problem won't get any worse (since no new traffic is there to be collected), but it does not protect the service's users against the real threat.

Marlinspike recommends two other email projects worth following rather than further work from the Lavabit team. Although he has not made comments about Dark Mail directly, Marlinspike does express disinterest in donating to Lavabit founder Ladar Levinson's Kickstarter project, which involves both releasing the Lavabit source code and developing Dark Mail. The Kickstarter project is titled "Lavabit's Dark Mail Initiative" and says:

Marlinspike concludes his analysis with words of caution about Lavabit:

Instead, Marlinspike points his readers toward Mailpile and the Leap Encryption Access Project (LEAP). Mailpile (which we looked at in September), is a local mail server with a web UI that does not rely on third-party storage. LEAP is an effort to build an easy-to-deploy encryption system for service providers. Email is one of several use-cases targeted by the project. Marlinspike also suggests following Trevor Perrin on Twitter in order to follow the latest on Perrin's work developing a secure email protocol.

Of course, even that list of secure email replacements is far from exhaustive. At least five others are mentioned in the comments on Marlinspike's blog post (BitMail, FlowingMail, Mailvelope, Pond, and Scramble). Ultimately it is impossible to meaningfully assess the security of any protocol or application that has not yet been deployed, so the final word on the Dark Mail Alliance remains out for the foreseeable future. As Marlinspike's critique points out, however, high publicity does not guarantee security. The Lavabit shutdown debacle certainly had the world's attention, but the approach it took to security might not be the best one to bank on from here on out.

Comments (9 posted)

Security quotes of the week

Comments (5 posted)

A Critique of Website Traffic Fingerprinting Attacks

Mike Perry has written a detailed article posted at the Tor site that looks at "website traffic fingerprinting" attacks—that is, attacks in which "the adversary attempts to recognize the encrypted traffic patterns of specific web pages without using any other information." In particular, he examines recent publications claiming to be able to recognize specific pages in encrypted Tor traffic, and finds the claimed results less than convincing. The issues vary from study to study, but small sample sizes and false-positives are among several recurring factors. Perry concludes: "It is likely that in practice, relatively simple defenses will still substantially increase the false positive rate of this attack when it is performed against large numbers of web pages (and non-web background traffic), against large volumes of Tor-like traffic, against large numbers of users, or any combination thereof." He does, however, suggest steps to improve subsequent studies, in addition to suggesting countermeasures for Tor users.

Comments (none posted)

OpenSSH 6.4 released

Full Story (comments: 16)

freeradius: denial of service

Comments (none posted)

java-1.5.0-ibm: multiple vulnerabilities

Comments (none posted)

java-1_6_0-ibm: unspecified vulnerability

Comments (none posted)

java-1_7_0-ibm: multiple unspecified vulnerabilities

Comments (none posted)

java-1_7_0-openjdk: multiple vulnerabilities

Comments (none posted)

kernel: denial of service

Comments (none posted)

libav: multiple vulnerabilities

Comments (none posted)

libvirt: privilege escalation

Comments (none posted)

libxml-security-java: xml signature spoofing

Comments (none posted)

lighttpd: multiple vulnerabilities

Comments (none posted)

maas: two vulnerabilities

Comments (none posted)

openssh: restriction bypass

Comments (none posted)

openstack-keystone: unintentional role granting

Comments (none posted)

poppler: multiple vulnerabilities

Comments (none posted)

quassel: denial of service

Comments (none posted)

rubygem-ruby-openid: denial of service

Comments (none posted)

spacewalk-java: unauthorized admin users

Comments (none posted)

spip: multiple vulnerabilities

Comments (none posted)

wireshark: denial of service

Comments (none posted)

xen: denial of service

Comments (none posted)

xen: denial of service

Comments (none posted)