A Critique Of Lavabit by Moxie Marlinspike

http://www.thoughtcrime.org/blog/lavabit-critique/

 

Interesting piece.

 

I think Marlinspike's argument that the Lavabit was really more of a won't read system than a can't read system is fair.

But I wonder if it's truly possible to create a can't read system. On some fundamental level, you are always trusting the devs of the software and systems you use.

For example, there's Countermail, that encrypts email clientside, through a java applet. This may be truly can't read. But they could always modify the java applet to make it do something other than what they claim it does. How would I know? They could be forced to do so under some sort of duress. (I like Countermail by the way, I'm just trying to make a point.)

Similarly, the projects Marlinspike advocates, Mailpile and LEAP. I have to assume that the clients they create do what they say they do. Even if the projects are open source, I have to assume that people in the community who I trust are really reviewing every line of code and no software updates introduce security backdoors (hasn't this already happened, unnoticed, in some open source projects?).

It seems the only way you could be sure that a system is not compromised is to write it yourself or review every line of code yourself, before using it. Many of us (myself included) do not have these skills. And obviously that is not a solution for more than a super tiny handful of people. Then I would have to set up the systems of everyone else I communicate with myself, to be certain for myself of their security.

I'm not saying that email can't be a lot better than what it is. Nor am I suggesting that open source isn't greatly preferable for security and privacy.

What I am saying is that although Marlinspike is correct that hypothetically one could technically create a true can't read email system. From the persepctive of the non-expert user, there is no way to avoid the element of trust, which make's can't read at the end of the day inherently hypothetical and not pratical.

That being said, I do still look forward to new better systems, like Mailpile and LEAP, as well as others.

 

Many salient points in your post cb. I'm afraid for the most of us the best we can do is trust that with the open source community there are many more unrelated eyes watching the coding than proprietary SW. I wonder what the real world figures are though, of those who actually examine the code?

Its way above my head but probably a better question would be how many times would the code be scrutinized in its entirety? At the end of the day even I can get it how open source is infinitely more to be trusted than closed.

 

Yes, I don't mean to downplay the benefits of open source and the possibilities of email that is far more secure and private than what is commonplace now.

On the other hand, I think your point is well taken, that although in principle opensource can be scrutinized by anybody, how well does this really play out in pratice?

Like Marlinspike's can't/won't distinction, it's another area where the hypothetical best case scenario may (or may not) be far from the pratical reality.

 

Excellent analysis, thanks for the link!

 

A provider, if they are trying to make money (even if just to pay for bandwidth, op costs, etc..,) has to try to make it usable for as many as possible. This will obviously make the most security minded of us, nervous. I think the best way, is to offer ALL possible options, and let the user pick degree of difficulty.

Moxie's review was spot on. This was known for a while, as even Steve Gibson said as much in the past.

Back to options: You mentioned Countermail. They have a better setup than Lavabit did, as you mentioned, but they also offer the user even more options:

You can REMOVE your private key from their server if you want.

You can also NOT USE the Java Applet (which they tell you how to verify, if you want) and use Thunderbird with Enigmail.

You can even not use their keys at all, and upload your own public key for encryption of incoming plaintext mail.

You can always connect to them via VPN if you want, and T-Bird can be set up to use Tor as well.

I don't think they get enough credit in this current climate.

PD

 

@PaulyDefran

I agree that Countermail is great and if used thoughtfully can provide great privacy.

I was only trying to making a technical point, just as Marlinspike was, but which I think Marlinspike's article does not acknowledge. My point was that it's hard to get around the element of trust. Marlinspike draws a can't/won't read your email distinction, but he only considers it from a technical point of view.

Technically it's possible to make a can't read your email system. Technically Lavabit was ultimately a won't read your email system.

But pratically speaking, as I say above, unless you verify every line of code in the software yourself or write the software yourself and unless you personally set up and verify the systems of all people you are communicating with, then you don't know that the technological is actually being implimented as claimed. You are trusting others that it really is the "can't read" system that they claim.

So on a certain level, "can't read" is more of a hypothetical technical possibility, than a practical possibility. Just as people had to trust Lavabit not to hand over the ssl keys. People have to trust Countermail's system to be doing what it says it does, people have to trust Thunderbird and enigmail and PGP and all of it. Unless you've verified the code yourself.

So I think that there is no such thing in the real world as a can't read system that has eliminated the problem of trust.

But my point, again, like Marlinspike's, is a theoretical one. Practically speaking I do trust certain people and communities. Practically, I think there are better and worse ways to organize communties and systems for trust, like opensource. And practically, I think it is possible to have a lot better privacy, through services like Countermail, and perhaps one day Mailpile and LEAP.

 

I don't use Countermail, but I recall from our last discussion that one can:

1. sign up for Countermail and create a key pair
2. configure Thunderbird and Enigmail
3. delete the initial key pair
4. create a new key pair locally
5. send just the public key to Countermail

However, that prevents Countermail from storing message headers encrypted.

I wonder if they can use a different key pair for their storage encryption.

I agree.

 

No, I agree with almost all of that. (Hope I don't come off as a fan boy here, just a customer, but talking about details makes everything more secure for all of us) In re: Countermail -

I see only 1 place where you have to trust them if you:

Connect to their https website via VPN, Tor, or a combination (hereafter known as VPNTC)-

Set up the main account with a name unrelated to you -

Pay with washed Bitcoins using VPNTC -

Verify the Bouncy Castle Java Applet -

Create a keypair locally and upload -

Set up all options and alias' -

Upload a NEW Public PGP key that you created with GPG -

Delete all initial web/java CM created keys -

(All of the above has to done using the web interface for initial setup - from here on out, you can never use the web or Java ever again)

Setup Thunderbird & Enigmail and only ever connect to CM with that, via VPNTC-

All keys are local, and you are now using GPG locally, and all keys are ones you created. If you want, you can move all mail to local T-Bird folders on a TC hidden volume.

The 1 place you have to trust them, is with their encryption of incoming plain text mail...BUT, this isn't really true either, because if they added an ADK (Additional Encryption Key), PGP Dump/Packets would see it, and they provide that service on their site as well. They specifically answered this question in another thread and said "we don't, but don't trust us, check it yourself and we provide the tool to do so, or you can do it locally".

I see nowhere where you have to trust them using the above method, but lets hammer it and see what I'm missing. Obviously, there are things out of CM's control, like a global adversary grabbing unencrypted headers/content leaving Gmail, enroute to you, that may give away details to who you are (family emails, etc...). But really, for stuff like that, just use another Gmail account if you can't run your own server. An IRL alias on CM may be good enough too, but I haven't fully researched if any correlation can be done on a CM alias and the main account creator...that would be a question for CM support.

Mirimir - You can add any public key to the account, for the CM engine to encrypt to ***I THINK*** Another question for CM support I'd imagine.

PD

 

I get confused every time I look at their (CM) website, in that I start asking myself what can I really use this for? Normal email (doesn't look like normal email senders can use it, or that recipients not set up for complexity can use it).

As to trust, there's this promise on the CM website that they do not log IP addresses. Isn't that a big deal? Don't you have to buy into that with only trust as your safety net? Are they going to shut down the whole thing if NSA or another country's version of NSA demands they do log IPs for a certain account in the future?

__

 

Lavabit founders's response to Moxie Marlinspike:

Op-ed: Lavabit’s founder responds to cryptographer’s criticism

__

 

@PaulyDefran

I think your knowledge of all the technical aspects of how Countermail's system works exceeds mine, so I don't know that I can effectively poke holes in the scenario you outline, assuming there are any.

As I said, you're still trusting the Thunderbird, Enigmail, PGP code, even if everything else is secure with Countermail, as you outline it. There's a lot of good reasons to trust that code. But it still requires trust.

I don't know that I fully understood the technology you explain that would make it clear if Countermail is using an ADK with incoming plaintext email. But what is to stop they from hypothetically simply copying the email and storing it elsewhere for the powers that be, before encrypting it? Wouldn't that be trivially easy? It seems like there's trust required there. And couldn't they do it with outgoing plaintext email also?

Also, even if one creates one's own public key, as you suggest, Countermail could still track and log the meta data, right? There's no way with SMTP to send email with encrypted header information, correct? I mean, Countermail can store the emails with the header information encrypted, but it has to be unencrypted for sending and receiving, doesn't it? And they could also log IP addresses, as S.B. suggests. So those are all areas where trust is required, no?

 

Thanks. Does seem like perhaps Marlinspike misunderstood some aspects of Lavabit's system.

 

See this:

Sure, but anyone sending clear text, should assume it is scarfed up anyway...heck of a lot quicker than subpoenaing CM

Yes, but they have no idea who you are (so IP logging would be moot), and again everyone should know that clear text and headers are considered "seized" the minute you click send. My use scenario was two privacy minded individuals communicating OR 1 user communicating harmless garbage to people who don't know him or her. If two users use CM, forget about it, the metadata never hits the net. Also If you are unknown (VPNTC with Bitcoin) the metadata can't tell much. Who talked to who, when, and a subject line

I'm not saying email doesn't have major problems, just that you can lessen the attack surface considerably with certain methods. Lets face it - if you *really* want to send something sensitive, you'll PGP it through Bitmessage via VPNTC...or OTR it over VPN/Tor/XMPP.

PD

 

Maybe, but what Marlinspike said is still valid. Ladar just managed to admit that his email system was not as great as people thought it was. And given the way that webmail works, I'm not sure that Lavabit could've been any better than what it was. But still, it was not the "perfect" system that Ladar implied it was...

 

As I see it there's a question of fairness here. Marlinspike claims that Lavabit wrongly told its customers that Lavabit administrators "can't read" customers' emails; whereas according to Marlinspike the truth was Lavabit was merely promising its administrators "won't read" customers' emails. Marlinspike also claimed that "The ciphertext, key, and password are all stored on the [Lavabit] server..."

All of these claims by Marlinspike were false. The truth was:

"Lavabit didn’t record any personal information in its log files. If the feds subpoenaed a user’s metadata from our log files, we had nothing to surrender. If the account was using the secure storage feature, any e-mails stored on the server were encrypted. This left nothing of value to turn over. In other words, I could not access or capture any of the plaintext e-mail content and surrender it because the only place user e-mails were available in their plaintext form was in memory or inside the SSL tunnel while traveling down the wire.​

In addition Lavabit servers were designed to prevent access to any unencrypted customer data on the servers:

Marlinspike claims that if an attacker gained access to a Lavabit server, they would be able to get users' e-mails in their unencrypted form by extracting the data from memory. With most systems he’d be correct. The Lavabit mail daemon, however, was designed to resist efforts to access the memory allocated to it by the operating system. Specifically, the daemon allocated a region of “secure” memory (an area of memory designed to resist snooping) and used it for storing sensitive data such as passwords and encryption keys. ​

Lavabit never claimed a perfect email system but instead warned its customers:

"If you’re intent on hiding your communications from the government, we recommend you investigate systems that secure messages throughout the entire e-mail system and not just at one particular point along that journey."​

There was however a soft spot in the Lavabit set up that Lavabit's founder acknowledges as follows:

"It never occurred to me that the feds might demand Lavabit’s SSL key. It simply wasn’t part of my threat model. If I were to highlight one of my personal failings in this ordeal, it would be that oversight."​

***​

Why does any of this matter? The answer is that security lies in the details. Lavabit's founder acknowledges that he overlooked a critical detail. But Marlinspike also got the the security details completely wrong.

The bigger picture involves questions of; how much snooping power does the government have? and under what circumstances will the government use that power? The answers to those questions are just coming to light. Not only does the government have snooping powers it denied having, but it also uses those powers in ways it said it didn't and wouldn't.

Can email ever be completely secure and/or anonymous? Can any internet transaction ever be completely secure and/or anonymous? If the adversary is big government that isn't held to any rules, the answer is, probably not. IMO Lavabit's founder can't fairly be blamed for that.

__

 

I tihnk S.B. already pretty much responded to this. But, along the lines of what he says, if you actually read Levinson's description of what he was doing with Lavabit, on the website, long before recent history, he really was not hiding the true nature of his system or making false claims about it. There was lots of long detailed information published on the website. And if you emailed Levinson he was happy and honest to provide further explanation (I did long ago and he was incredibly forthcoming).

And it also was true that after the fact, encrypted email, on his server, could not be decrypted without the user's password. So that part of the "can't read" claim, I believe is correct. What Marlinspike covers has more to do with the SSL keys and access to new incoming or outgoing email.

 

But if they have your IP address presumably the powers that be can track down who that address belongs too. Of course you could be using a VPN and Tor, etc., to make that more difficult. But still, the no logging claim, for the sake of my point, is a trust us claim.

I agree that plain text is not secure. And I agree that two CM users will have pretty decent privacy. You still have to trust the PGP encryption and other (I assume open source) elements of the system.

That may seem like a silly thing not to trust. But it is interesting, looking at some recent threads here, that even with TrueCrypt, a very popular opensource encryption software, it's hard to know how well the software has been fully vetted. People are still trying to come up with a good way to audit it. See:

https://www.wilderssecurity.com/showthread.php?t=355637
https://www.wilderssecurity.com/showthread.php?t=353108

I'm not saying Truecrypt shouldn't be trusted or that I believe the honeypot theories. But it's just interesting how hard it is to be sure something has been effectively audited. The principle of open source being more secure is a good one. Whether in practice the code has really been vetted seems pretty open to question, when you have something like Truecrypt still difficult to verify. And then you have to trust the people doing the auditing.

Anyway, just to say, yet again, there are a lot of points of trust, I think, even in a system like CounterMail.

I think you know what I'd say about PGP. But anyway, I agree, one can lessen the attack surface a lot. And I do trust these systems and hope to see more people using them. My main point has just been all along that Marlinspike's can't/won't read distinction probably is really only relevant in theory. In practice "can't" pretty much always, no matter how good the software and system, is functionally really something more like "won't." So on that basis, I think his position that on one side there are people like Levinson and Lavabit and on the other some sort of purely technical solution that is qualitatively different, ignores certain pratical realites that technology can't really obviate. Once the system is deployed in reality, by people, its theoretical "can't" nature is inherently transformed into "won't."

 

"Praise the Lord and Pass the Ammunition"

 

AFAICT, they are actually true. Marlinspike posted two images of Lavabit pages. In the first we see:

and in the second we see:

We would not be gentle when critiquing such claims. If ANY Lavabit personnel could arrange to read ANY email (other than their own) at ANY time then we'd consider the "can't read" claims to be inaccurate.

A large percentage of MTA-MTA traffic is unencrypted due to at least one server not supporting STARTTLS. Many email providers don't support it, and some if not many Lavabit users were surely exchanging non-end-to-end-encrypted emails with users of those providers. Even in cases where they were using end-to-end encryption, some metadata would typically be unencrypted. So a simple network capture on the appropriate machine/interface should have sufficed to read many full emails and some email metadata) flowing into and out of Lavabit servers. If Lavabit disabled STARTTLS support on their servers then none of the MTA-MTA connections should have been encrypted and even more emails would be vulnerable to simple capture/reading. Note: Marlinspike doesn't even go here. Possibly because he understands how SMTP systems work and realizes that such issues are expected, possibly because he wanted to focus on the storage side encryption/decryption issue, I don't know.

On the storage side...

So Lavabit could, at its discretion, configure the server to expose, for someone's reading, the plaintext password, the user's private key, and the user's stored email.

The paragraph you ...'d off:

An accurate description and the crux of the problem.

 

A "server" is a combination of hardware bundled together with software rules. Similarly the Lavabit servers were a combination of hardware and software as then configured. Lavabit's claim that its administrators "can't read" the emails was based on the actual system, and it's actual servers, as configured.

Of course it would be possible to change the Lavabit software, and hence the Lavabit servers, just as encryption software, like TrueCrypt, could be modified by inserting a keylogger into the software. In such cases, the modified security products would be insecure.

Lavabit never claimed that its system couldn't be changed. Analyzing the Lavabit "can't read" statements as though they were "can't modify" statements is both unreasonable and unfair.

__

 

Yes, this is why I've kept arguing that Marlinspike's "can't read" concept is entirely theoretical and not realizable in the real world. Once you realy on someone to impliment a technological solution for you, you're trusting that it does what they say it does. Unless you write the code or verify every line of code yourself (and perhaps verify the hardware too), you're trusting someone else. In a sense, I suppose Marlinspike has created a distinciton without a (real world) difference. That's not so say that there aren't reasons to trust people and better ways to establish trust (like open source), but the idea that the trust element is entirely eliminated by the technological design I think is false in any real world application.

 

To me the attacks on Lavabit and its founder, Ladar Levison, are incredibly short-sighted and also incredibly ironic given that Levison actually shut down Lavabit to ensure that Lavabit's promises of email confidentiality weren't thwarted by government actions. Seems to me that Levison's actions have established the trustworthiness of Lavabit and his (Levison's) promises way beyond any shadow of a doubt.

Against the background of Levison's actions and the lengths he went to in order to keep his promises, the attacks on those promises are just flat out wrong IMO.

If there ever was a case of "the proof is in the pudding", this is it.

__

 

This isn't about Ladar Levison or others who may have contributed to Lavabit. It is about systems... how they are implemented... what can/can't be done by those that should be in control of them... and what can/can't be accomplished by others who through legal force or penetration or bribery or blackmail or whatever can acquire control of them. Just pretend the comments apply to a system exactly like Lavabit but one that is run by others who are less scrupulous.