A Critique of Lavabit

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

by tptacek • 13 years ago

245 118 13 years ago

dmix• 13 years ago

Great analysis. This is mainly why I didn't donate to Dark Mail even though I fully supported Mailpile and Lavabits legal defense.

What about Silent Circles involvement in Dark Mail? They came under criticism for not being open-source in the past year.

Sure they have Phil Zimmermann but I'm curious if he is already too much focused on his own business to not fully be able to contribute to Dark Mail. Compared to say some new eager hackers willing to focus on this full-time. Do both Ladar/Phil have the focus/ability to create an entirely new OSS email protocol?

MichaelGG• 13 years ago

One big question is why they didn’t just get a CA to make them their own.

Isn't this because if they did, they could be detected by any user? And the CA could lose their CA status in browsers for improperly issuing a certificate?

js2• 13 years ago

It would only be detected if the Lavabit certificate was pinned by the browser. Otherwise the browser trusts the CA.

meowface• 13 years ago

You're right, but if even one person uses certificate pinning, they could make a post somewhere saying "hey, Lavabit's SSL certificate just changed, any thoughts?" and others may suspect that something fishy is going on. Especially if it were to occur after the NSA leaks.

mseebach• 13 years ago

There's that, but there also the lazyness angle. Why go with a complicated, detectable technical solution when you can send out a NSL and have someone else do the heavy lifting for you? I strongly suspect Lavabit's reaction wasn't in any way expected.

mtgx• 13 years ago

Disregarding the metadata problem for a moment, wouldn't it be possible for all major e-mail providers to integrate PGP in a user-friendly way, with public keys tied to their accounts (so you wouldn't need to know someone else's public key, just their e-mail address), and then do something like Ladar is proposing with the green light/red light thing for PGP to PGP email providers and for PGP to non-PGP e-mail providers?

So in the end, isn't that more of a will problem than a technical one? DarkMail would obviously face the same adoption problem, unless it's somehow much easier to set-up for both the e-mail providers and the user.

Besides that, I think they proposed an extra security layer to encrypt the metadata, too - wouldn't that be possible for a PGP-based system, too?

StavrosK• 13 years ago

The providers are the people we can't trust.

jere• 13 years ago

>There is no way to ever prove or disprove whether any encryption was ever happening at all, and whether it was or not makes little difference.

I get that Lavabit was fundamentally flawed, but I don't know about this part. Lavabit saying they can't read your email seems analogous to any website that requires a password saying they can't read your password, because it is hashed. That's an important and reasonable claim, right? It means at the very least all the passwords/emails can't be download in bulk and read immediately.

You don't know for sure what hashing methods are being used on any given site, but to say it doesn't matter at all.... is kind of like saying the operators should just leave all of your passwords in plaintext in the database because they could intercept them at log in anyway.

hyperpape2• 13 years ago

I think the point is that while it does matter in some ways, it doesn't matter for security issues Lavabit claimed it addressed.

Think of a site that says your password is secure. When you call them on it, they say "well, we do store your passwords in plaintext, but we use SSL to transfer them."

Dylan168073• 13 years ago

I don't understand your analogy. 100%* of sites with passwords use the same method, transmitting the plain text to the server where it is hashed and discarded. Do you want 0%* of sites to claim that passwords are secure, even if they use a well-configured bcrypt and follow best practices?

*rounded to the nearest percent

gknoy2• 13 years ago

No. It matters because courts have ruled that your system cannot claim "averting its eyes" as a defense against providing intercepted data.

Recent (in the past year) court rulings have decided that passwords in memory are accessible, even if your softwre normally throws them away -- so you could be legally compelled to implement interception of those. (IANAL, and this assumes that I understood the things others wrote about these...) Sure, it's likely only in some circuits, but I'd be surprised if other judges did not rule similarly.

A safer system would be where YOU create your own key pair, and only send your public key to the secure mail provider. You know that your e-mail, your text, etc is never in cleartext on the remote system, which means that even if that system is completely compromised, all an attacker is getting is encrypted copies of your communications. (Well, and cleartext metadata, since you need that for sending mail.)

In such a system, you know that encryption is happening, because you are doing it on your computer before sending bits to the server. (You'd also need a way to exchange keys in a way which doesn't require trusting the secure server not to be MITM-ing you.)

Even that's likely not fully safe, but it's very different from having the server avert its eyes and pretend you never sent it plaintext keys/credentials.

jedbrown• 13 years ago

you know that encryption is happening, because you are doing it on your computer before sending bits to the server

If your server receives email for you over SMTP, you are trusting the server not to log a copy before encrypting, trusting that there is no intruder on the server, trusting that someone (like the NSA) is not logging traffic between servers, and trusting the sender's machines to the same.

Similarly when you send email in a way that can be read by your recipient's provider. You have to encrypt for an individual, as with PGP, for there to be meaningful security, at which point your provider's "secure" practices are only covering a bit of metadata, some of which will be leaked when communicating the message.

The problem with PGP is that it has a complicated trust model, poor client integration, and does not provide forward secrecy. The first two may be fixable via better user interfaces (which includes breaking from traditional webmail) but forward secrecy would need protocol support is in conflict with the asynchrony email currently enjoys.

betterunix5• 13 years ago

"is kind of like saying the operators should just leave all of your passwords in plaintext in the database because they could intercept them at log in anyway."

Actually, as with encrypted email, the cryptography research community already knows how to solve that problem:

https://en.wikipedia.org/wiki/Zero-knowledge_password_proof

basch2• 13 years ago

What about something similar to dashlane.

You type in your username, it downloads a payload, then you type in your password and it is decrypted locally. Your password never leaves your machine.

jtheory5• 13 years ago

Isn't he glossing over some actual value in a private Lavabit-like setup?

He's quite right that there are several steps where the server must "avert its eyes" (this is a good way to explain it) to keep the plaintext password, decrypted private key, and resulting plaintext email safe.

But still, if the server averts its eyes at those points, once the user has logged out of webmail, the email is again safely stored, and (as claimed) even an NSA-compromised Lavabit can't access them until the user signs in again (if the server has been modified to capture the password or private key).

Well... except for the loophole where the emails were transmitted plaintext via SSL, NOT using perfect forward secrecy. In that case, anyone who managed to capture that SSL-encrypted traffic can decrypt it after the fact if they can get the SSL private key from Lavabit's servers.

And honestly, that was the weakest point. Once Levison shut down Lavabit (preventing Snowden from sending in his password again), Snowden's emails were safely locked away, except for that last loophole.

What this all suggests is that an open source version of Lavabit could actually be more valuable than the original service, as long as SSL is configured for perfect forward secrecy.

I.e., set up & secure your own email server (or let a trusted person do it for you), with code that verifiably averts its eyes at the critical moments, and leaves your email history safely encrypted when you're not accessing it. If you ever suspect your server may be at risk or has been compromised, you simply don't sign in again.

Marlinspike is right that the best solutions are in sticking with email clients (not webmail... unless you want to dig into the problems of real encryption/decryption in JavaScript, and verifying the JS you've just downloaded). But -- those solutions don't exist yet, and may not exist for years to come.

A private Lavabit seems like a pretty solid solution to me, and certainly far better than throwing up your hands and going with gmail and friends.

[minor edits for clarity]

sillysaurus22• 13 years ago

Lest anyone seriously consider this, keep in mind that the success of cryptography is that you don't need any "blind faith". Properly designed crypto systems are those which don't force you to lean on any pillar that might give way unexpectedly.

"Just trust the server to avert its eyes" is untenable. It's untenable because it's unnecessarily risky. We as a community can do better than to use someone else's design full of holes merely because it seemed to work.

Crypto systems seem to work until they don't. And when they stop working, it's likely you'll never realize. But your adversary will.

jtheory5• 13 years ago

"Unnecessarily risky" depends on what options you have available to you. The problem here (as I mentioned) is that a more solid solution is probably still years away -- and even then, email is a very difficult thing to secure end-to-end, so the possibility of user error exposing an email you imagined private will not go away for a very long time.

My main point above was that while the original Lavabit did require you to trust Lavabit (who could be legally compelled to start logging passwords...), a roll-your-own version would shift that trust burden from a US company to you or whoever sets up your server.

I'm not claiming it's the final solution -- just that it would be significantly better than nothing.

There's value in continuing to push for full solutions; but that doesn't mean there's no value in options like this, just as yes, you're a fool if you rely on security by obscurity, but that's not the same as saying that it can't add to your security in a real world situation.

rosser2• 13 years ago

For a scenario like the one Lavabit was trying to address, trusting the service provider to "avert its eyes" isn't good enough. If I'm Edward Snowden, I need to assume that my service providers are all actively hostile to my interests. Crypto that doesn't protect me in that environment can't be trusted to protect me in an "non-hostile" environment, either.

jtheory5• 13 years ago

Right; I was talking about the private version of Lavabit, where you aren't obliged to trust a service provider.

djjaxe4• 13 years ago

Wouldn't Lavabit be better if all decryption was done on client side, either with javascript or a client side add-on/extension? This way the only thing that is ever on the server is the public key? The only thing left would be if it had been in a man-in-the-middle attack... which is always an issue on the internet unless every part is encrypted which is hard to do... though internally it could potentially be safe as it would not ever be sending out of itself and emails being sent would also be encrypted client side using javascript/add-on/extension... (also have the keys generated on client side) yes this would inevitably be a large client side program but for security it would be worth it.

marijn• 13 years ago

This is a tempting approach, but man-in-the-middle attacks, or the equivalent compromised or legally-strongarmed servers are the whole problem here. Any client-side logic that is served by a server can only be trusted as far as that server (and your communication channel to it), which means that in this case it's almost useless.

There doesn't seem to be any serious alternatives to thick, open-source, locally installed clients. As a web affectionado and JavaScript nerd, this pains me too, but we'll have to get used to it.

djjaxe4• 13 years ago

Then I think it's time to look at a mail system that doesn't need servers something built on top of the bit torrent grid or similar system that the government can watch all they want but won't get any information back from it and have it completely open source... this will take out man-in-the-middle and a central server compromised issue and there will be no one to legally strong-arm.

djjaxe4• 13 years ago

And good point I forget that the web is basically insecure from government intrusion :[

MagicWishMonkey2• 13 years ago

This is a terrible writeup.

>There is no way to ever prove or disprove whether any encryption was ever happening at all, and whether it was or not makes little difference.

That is the whole point in open sourcing the code!

dsrguru• 13 years ago

Are you saying that releasing a similar system under an open source license will prove claims about the way their code worked in the past or just that we'd know if encryption is happening in the open source system?

tptacek6• 13 years ago

That is a dumb comment. Open sourcing the code doesn't mean you know anything at all about what's actually running on a server purporting to use the open source code.

stcredzero2• 13 years ago

Now, if such Open Source systems could be compiled with a mechanism that could ensure that only "blessed" executables could run, and if there was also a process where 3rd parties could compile their own executable and verify what is executing on the server, then there would be a solution to this dilemma.

Unfortunately, that would be DRM, which evokes knee-jerk cries of "Evil!" The point here is that DRM is not fundamentally evil. The particular way that lots of companies want to use it and slip it into everyone's machine under the radar is most certainly bad. However, there are situations where it would actually be useful and help protect individual rights. (In particular, when it is used by individuals as a tool to protect their own interests.)

(Yes, I know I'm preaching to the choir, but this is really for 3rd party readers.)

jsmeaton• 13 years ago

The court order basically told lavabit to modify the code to provide the access they were seeking. Even if the code was open sourced, you can bet that the requested modifications wouldn't have been.

insertnickname• 13 years ago

If someone else held the copyright to the code and it was licensed under the AGPL, then it would be illegal to not open source such contributions. Of course, the government could work around this by providing their own mail server software or by just disregarding it.

mattkrea2• 13 years ago

Aren't these problems with Lavabit related to the fact that they still had to support plain old SMTP coming and going?

Dark Mail is intended to be a new protocol.. not just a new Lavabit (which would mean, theoretically, that it could be point-to-point secure)

eridius• 13 years ago

Assuming you meant plain old POP/IMAP, then yes, I think that's the root problem.

mattkrea2• 13 years ago

I meant SMTP as that is the protocol used between servers and that is where some encryption should really start.

jcrites2• 13 years ago

Is there something to read about how Dark Mail will work? I'd be interested to contribute, help build an implementation, or add support in products I work on.

MagicWishMonkey2• 13 years ago

That's exactly the issue here, it's not possible to provide perfectly secure email without completely re-inventing email from the ground up, breaking compatibility with existing systems.

Ladar NEVER made the claim that he re-invented email, the people here who say he misled people are out of their mind.

tnorthcutt2• 13 years ago

I have two alternate recommendations:

Mailpile. Despite what anyone tells you, end to end encrypted email is not possible in webmail a world [sic]. The first precondition for developing a usable and forward secure email protocol is a usable mail client, and I currently believe that Mailpile is our best shot at that.

From [0]: mailpile A modern, fast web-mail client

I am honestly confused. It sounds like Moxie is saying a webmail client is not the answer, but then he recommends a webmail client? I'm not trying to be snarky; I'm genuinely curious.

0: http://www.mailpile.is/

philosoft• 13 years ago

I believe he is referring to a web-mail service hosted by a third-party having inherent insecurity. With mailpile, you run the service on your own system.

pyre• 13 years ago

From their IngieGogo[1]:

  Mailpile is free software, a web-mail program that
  you run on your own computer, so your data stays
  under your control.

[1] http://www.indiegogo.com/projects/mailpile-taking-e-mail-bac...

bradleyjg3• 13 years ago

So the POP client is being built on top of an HTTP server? And I access it via a web browser pointed at localhost?

Does that sound crazy to anyone else? It makes me think the authors have a hammer (i.e. web development skills) and therefore think everything is a nail (i.e. a webpage).

If I have to install software anyway, I'd much rather it be a full fledged native client. One that looks, feels, installs, uninstalls, and is configured just like all the other native programs on my machine. I had such a program in the late 90s/early 2000s. It even had support for SMIME and PGP.

aeturnum• 13 years ago

I am not familiar with mailpile, but I imagine it uses client-side implementation of PGP with automatic public key exchange.

moxie2• 13 years ago

I don't think we've quite worked out the language here yet.

I use "webmail" to refer to a remote hosted web interface. GMail, Yahoo Mail, Hotmail, riseup.net, etc. This is the dominant way that people access email, and it's not possible to secure well because of the "webapp crypto problem."

Mailpile, on the other hand, is a locally hosted MUA that happens to use your web browser as the UI. I think it's a great idea, leveraging the UI properties of a web browser, but with everything running locally.

All development of a new secure email protocol has been stymied for the past 13 years by webmail. It is not possible to provide end-to-end encryption if you don't perform that encryption on the client side, and in the webmail world there is no "client."

I'm excited about Mailpile because it could be what gives us a usable local MUA, which is the precondition to deploying a nice, modern, usable, end-to-end encryption protocol.

tnorthcutt2• 13 years ago

Thanks for clearing that up for me.

rsync2• 13 years ago

web hosted MUA < curses client over SSH [1]

[1] like pine

tlrobinson2• 13 years ago

As I understand it, Ladar's plan for Lavabit is to open source it (and implement the Dark Mail protocol) so you can run your own instance of it... exactly like Mailpile.

igravious7• 13 years ago

Could some please please please explain what this "webapp crypto problem" thing is. I think of a browser as a client. Isn't the javascript done client-side. Why is everybody saying that the browser (javascript) is a broken platform for crypto. Have a even characterised what the issue is correctly? I don't even know.

I figure that if this is explained to me then surely the solution should present itself at the same time :)

saljam• 13 years ago

(A bit off-topic)

Locally hosted web apps are on the rise (Mailpile, Camlistore, etc.) and remembering which app runs on which port is neither user-friendly nor scalable. More so if you start to consider multiple users on the same machine.

Maybe there's a need for a usable reverse proxy just for local web apps?

It would also be neat if browsers could speak HTTP over some IPC that isn't TCP on some random port. Maybe UNIX sockets in ~/.run? This would delegate read/write permissions to the OS.

chacham15• 13 years ago

From the article: "Despite what anyone tells you, end to end encrypted email is not possible in a webmail world."

From above: "it's not possible to secure well because of the 'webapp crypto problem.'"

I REALLY hate these sort of platitudes because they sound authoritative with no real basis. "Not possible" is a very strong statement. One, as a matter of fact, that I am working on a solution to.

The so called "webapp crypto problem" that you refer to is the fact that you cannot trust that the provider will change the source on you at will to initiate an attack. This can be dealt with by having hashes to identify the piece of code that has been recieved. This hash is then looked up by multiple verifying nodes which will confirm the signature. These nodes can confirm the signature by looking at the source and matching it with the hash. This way you move the authority from the single issuer to the set of verifiers. Now, if the code is open source any individual can verify the verifiers.

This is a general overview of the system that can solve the "webapp crypto problem." Yes, there are details missing, but this should be enough to show you that it is indeed possible.

randallu• 13 years ago

Hopefully the new window.crypto stuff could be used to createa a hosted webmail service where the private key is generated in the browser and never leaves the browser.

tptacek6• 13 years ago

Probably not. Maddeningly, the W3C Web Crypto project decided to define a crypto interface in terms of primitives knitted together with Javascript, so, while you can probably assume WebCrypto AES is real native AES (assuming you're not dealing with polyfills, which is a real problem for any crypto extension), you can't assume the glue code in the cryptosystem is secure --- that's left up to content-controlled Javascript to define.

rsync2• 13 years ago

I typically don't go on about this, and I suspect it's dismissed by most, but ...

It's amazing (and amazingly satisfying) how much of this debate one can simply ignore when one uses ssh to log into an account and run pine (or elm).

A lot of this just becomes irrelevant.

Did you know that not one intercompany email at rsync.net has ever traversed any network ? It's just a local copy operation ... and no browser has ever touched them.

dsr_• 13 years ago

I assume you mean intracompany email. And you haven't changed to mutt? Mutt is like elm with fifteen years of clever development by people who actually like mail.

dllthomas2• 13 years ago

I like nmh...

cipher0• 13 years ago

I just switched to mutt and it's freaking awesome!

tptacek6• 13 years ago

I don't understand. When you run Pine from an SSH session, the mail you send is still being sent in plaintext over SMTP.

wglb• 13 years ago

So does this mean that all intercompany email is generated and read on one local host that everyone SSHs into?

PilateDeGuerre• 13 years ago

"Deserting the Digital Utopia: Computers against Computing"[1] might be of interest to HN readers as well. The whole piece is quite antagonistic to the HN worldview, and it ends on a sort of challenge to hackers. I submitted it as a link last week and the submission fared poorly then. I mention it here because I would like to see it read and discussed by this crowd.

[1] http://crimethinc.com/texts/ex/digital-utopia.html

gorklin• 13 years ago

I suppose this article faired poorly because of its length and a touch of the vague. I think the premise of an "ideal capitalist product" is either self-contradictory or ill-defined. The analysis of the digital panopticon, and its effect on interpersonal relationships is spot on.

I'll summarize what you might see as HN antagonism in this piece as "refinement of the current digital trends will only make worse appear better". If the digital utopia (another ill-defined term) refers to current-trend network panopticon, then I surely and emphatically agree.

But computers are faithful servants, nothing more. They are currently recapitulating existing hierarchies -- this is how We The Hackers have commandeered them. Who wants to write a distributed system when so much in our tool-belts makes client/server architectures a comparative breeze. It's no surprise that on the first try we've made our servants into centralization machines, into pyramid builders.

The network effects -- for or against hierarchy -- of most (maybe all) previous tech is hard-wired. The steam engine's effects, etched in steel, support hierarchy only to the point thermodynamics and Mr. Carnot will allow. Radio and television are inherently hierarchal, supporting one-way broadcast on account of the physical limits of electromagnetic transmission. There are a myriad other technologies, to be evaluated by these criteria, and I think Lewis Mumford has done a pretty thorough job of it [1].

As for our digital servants -- they aren't hard-wired. Decentralization may be non-trivial today, but when it works, it persists as long as the medium. Bittorrent isn't going away anytime soon, and DHTs are here to stay.

So by all means, leave the digital utopia you've been sold so far. Most popular fiction utopias were strictly controlled hierarchies anyway. Let's re-wire our servants to decentralize. We can fight the panopticon with the same silicon we used to build it. For in the end, the universe allows encryption.

[1] https://en.wikipedia.org/wiki/The_Myth_of_the_Machine

tlrobinson2• 13 years ago

I'd like to see a critique of the actual Dark Mail protocol. From the Kickstarter video it seems clear they're aware of the tradeoffs of a Lavabit style system, and are starting with a true end-to-end encryption protocol, with the option to "dial down" the security when necessary.

batemanesque• 13 years ago

the other aspect is that despite the whole reason for Lavabit's popularity in recent years being NSA stuff etc, their site freely admitted that they couldn't refuse to fulfil legal government data requests, but that users shouldn't be worried because that would only apply in the case of criminal behavior. which bizarrely, is the same justification many NSA-overreach supports use: "if you're not doing anything wrong, you've got nothing to worry about."...

also, I always found it slightly dishonest that the free tier they used to provide featured no special encryption, given that their stated reason for existence is to provide secure communication

RexRollman• 13 years ago

The real lesson is: don't depend on someone else's computer to perform the encryption process for you. If you do, it is susceptible.

vinceguidry• 13 years ago

I'm unconvinced that supporting other mail applications is a better bet than supporting Lavar. Regardless of his product claims, he's in a position to fight an important political battle for the rights of all of us. That's why I support him, because politics are the battleground here, not technology.

HelloMcFly• 13 years ago

I support his defense funds, but I don't support his products for the reason the article stated. Lavabit wrote a check they knew they couldn't cash. It wasn't the government's fault that he had the capability to compromise the promised security in the first place.

jrochkind12• 13 years ago

So support him by contributing to his political/legal efforts, but not contributing to or supporting his technological efforts, unless you understand the technology and really do support it.

mistercow3• 13 years ago

Despite what anyone tells you, end to end encrypted email is not possible in a webmail world.

Sure it is. You just have to do crypto in JavaScript.

relampago• 13 years ago

moxie, great read, ty.

This thread led me down the rabbit hole to your quest as a maniac sailor, in the epic Hold Fast. I must say, as a fellow romantic - this was a great piece of work. I was left inspired to seek out the "impossible." I recommend it to you all!

I think you did much justice to the art of sailing, the beautiful world of the ocean and the spirit of the human heart. Thank you so much!

A Critique of Lavabit

Related Stories