Lavabit was vulnerable to three attackers:

1) The server operator could choose to obtain access to plaintext. 2) An attacker who compromised the server could get access to plaintext. 3) Anyone capable of intercepting the SSL communication could get access to plaintext.

Incidentally, those are the exact same points of vulnerability for a normal (unencrypted) mail service.

One interesting question is why the US government requested Lavabit's SSL key rather than just getting a CA to sign their own. My assumption is because they were interested in past communication that might have already been deleted (perhaps by Snowden). We now know that the US government often logs and stores ciphertext, and we know that Lavabit was not selecting PFS SSL cipher suites.

So when Ladar did eventually provide the SSL key to the government, it's likely that the government was able to use that to decrypt all previously stored traffic and obtain the entire history of transmitted email.

So it's quite likely that Snowden (and all other Lavabit users) did have their email read by the government.

What is different about the government logging traffic between Lavabit and the user versus the SMTP between another host and Lavabit? With Lavabit's key, they can get all incoming mail (and many providers don't even use STARTTLS). Perhaps their logged traffic was incomplete or is difficult to search?

Email just isn't very secure as a protocol; people that care need something they can verify, like PGP (which Snowden used). It's unfortunate that the asynchronous nature of email (which we tend to view as an important feature) is incompatible with client-verifiable forward secrecy.

Are you sure, that Lavabit did not select PFS? Is this documented somewhere? That's quite a fumble for someboday advertising secure email services.

BTW: shouldn't we assume, that the US government operates at least an own intermediate CA for such purposes rather than getting single Certs signed.

Ladar says so in this interview, starting around 32:30:

http://www.youtube.com/watch?v=7LzKjxj0u_s#t=32m30s

He had the keys and encrypted messages on the server. Everything but passwords (to unlock the private key), which he received from users and chose not to store. There is no way for users to audit that the passwords are not stored or intercepted (with or without Ladar's consent). He took a commendable stand, but had he built the technology differently, he never would have been in a position of having to choose and users would not have to trust his integrity and endpoint security.

The technical challenge is in designing a system in which the server does not have to be trusted, but that integrates well with existing protocols. I'm not aware of a proposal that offers the desired level of security while transparently integrating with SMTP, but perhaps Moxie has ideas.

One can get part way if the users generate their own key pair and only provide the server the public key, then either use a PGP-capable mail client or perhaps run a local (open source and audited) IMAP proxy to decrypt. You'd still have to trust the server not to store a clear copy of incoming mail, but once it is encrypted, only the client would be able to decrypt.

FWIW, I think there's a disconnect between what people expect/need from their email hosting provider and the "obvious" security solutions. Especially these days with many many people relying on IMAP to provide server-side search when using mobile devices.

If you need the server to be able to text search through your mail archive (and I do that a _lot_ on my phone), you need to "trust" the server with your clear text.

If you don't want to run and secure your own server - you need to choose what level of compromise you're prepared to accept.

My current project is a mail server on a RaspberryPi, hidden behind my home NAT gateway and firewall, that opens reverse ssh tunnels for ports 25 and 465 to inexpensive VPSes configured to not log anything - with IMAP (and webmail) access limited to my local network (and to my phone and iPad via vpn). It uses Vagrant and Ansible to provision and configure VPSes on the fly, and DNS hosting with APIs that Ansible can update MX records for as my receiving mail server moves around different VPS vendors in different jurisdictions.

>If you need the server to be able to text search through your mail archive (and I do that a _lot_ on my phone), you need to "trust" the server with your clear text.

How many megabytes of body text are you searching through? Is your phone actually incapable of doing the search in milliseconds?

My inbox currently contains 5800 e-mails and takes ~500mb of disk space. Doing a full text search takes a bit, even on a laptop.

Disk space doesn't matter. That's going to be mostly extra headers and formatting and attachments. I can't find many sources for the number of words in an email, but what I did find suggests about 50. Let's assume that's an entire order of magnitude off, and you have 500 words * 5800 emails. That's 17MB. A laptop or a phone can easily cache that much data and search it in a tenth of a second. All you have to do is filter out the junk beforehand instead of repeating the work every time you search.

I have a million emails occupying 20GB, and receive several hundred per day. I search my mail archive using xapian (via notmuch) on my laptop, but such solutions are less practical for phones and even some desktop users expect IMAP search to work. Indexing is definitely a problem if you want the server's store to be encrypted.

You do not need the full text for search. You can hash every word and search hashes.

That sounds completely insecure.