Hacker News new | past | comments | ask | show | jobs | submit login

> Former Lavabit users will be able to access their accounts in “Trustful” mode

Looks like Trustful mode is how the old lavabit operated.

> If you're going to operate in "trustful" mode, lavabit isny offering any real security wins over any other mail host.

This level of security apparently was enough to protect email contents against FBI.

The reason this "insecure" mode is kept is to allow users to continue using their old accounts and restore mailbox contents: https://lavabit.com/have-lavabit.html




It may also be a very bad idea if Lavabit is compromised now. Don't try to connect to your old account if you had any sensitive emails.


Oh I didn't know that the contents of old accounts were now accessible again. Was that not deleted by Lavabit when they got subpoenaed?


I think Ladar deleted TLS key, not the database.

Well, https://lavabit.com/have-lavabit.html says: "With the help of these tutorials, you should be accessing your old Lavabit e-mail and sending new secure messages in just a few minutes." Maybe e-mail here means account, not messages.

I have some free accounts to test, but looks like imap.lavabit.com and smtp.lavabit.com don't have SMTP/IMAP/POP3 ports open.

Update: https://twitter.com/kingladar/status/822570163547541504 Database is not deployed yet.


How did it protect email contents from the FBI? They got warrants and got the emails.


Well, if you have not logged in since they started recording traffic and until shutdown, chances are your password is not compromised and emails are still encrypted. But no way to be sure.


Before the thing with Snowden and the cert, Lavabit simply complied with warrants, which they could since they could read everyone's email. Fundamentally, Lavabit was not in any way different than Gmail.


Any source for this? Reading everyone's emails requires them backdooring their server so that it saves plaintext password or symmetric key on login. Were they doing this?


'backdooring their server to themselves' is not 'backdooring' it's just misdesigning. The alternative is believing Lavabit always scrupulously 'looked away'.

https://moxie.org/blog/lavabit-critique/


We already know that Lavabit design was bad and that is why everyone is moving to E2E.

Still I found no evidence that Lavabit handed over anything but encrypted data and access logs. The only thing I found is [1]: "He says he's received "two dozen" requests over the last ten years, and in cases where he had information, he would turn over what he had. Sometimes he had nothing; messages deleted from his service are deleted permanently."

He has complied with warrants because he had nothing to transfer. Nothing was stored and there is no legal obligation to modify your service to store passwords. When he was asked for TLS keys, he had to shutdown the service to prevent leaking all the passwords and redesigned the server.

The difference between not looking away and Lavabit design is that nothing is exposed if the server is seized.

The design of old Lavabit was not sufficiently secure and there was no way to check if it is more secure from the users' perspective, but still no reason to call it snake oil [2]. Snake oil is a product that is advertised as secure when maker knows it is insecure. Lavabit design was correctly described on its website and source code was promptly published after the shutdown so it is possible to verify that described features existed.

[1] http://www.forbes.com/sites/kashmirhill/2013/08/09/lavabits-...

[2] https://news.ycombinator.com/item?id=13447919


Still I found no evidence that Lavabit handed over anything but encrypted data and access logs

There isn't any evidence of that or the contrary. He had all the data. We don't know what he did or did not turn over.

Snake oil is a product that is advertised as secure when maker knows it is insecure.

Take another look at this (and Moxie Marlinspike is being generous and sympathetic). It meets your own criteria precisely.

https://moxie.org/blog/lavabit-critique/




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: