7 ms·

Lavaboom: Zero-Access Encrypted Email Service Hosted in Germany

54 points by BillFranklin 11y ago

simi_ 11y ago
Lavaboom dev here, I'm happy to take questions. We're open source, mostly Angular and Go based: https://github.com/lavab https://github.com/lavab edit: just to point out, we're running a Indiegogo campaign! https://www.indiegogo.com/projects/lavaboom https://www.indiegogo.com/projects/lavaboom
- fiatmoney 11y ago
  "We use JavaScript. All encryption happens on your browser" How do you prevent the scenario of being forced to provide a poisoned client-side encryption payload, just like e.g. Hushmail was?
  - simi_ 11y ago
    1. Our code is public. https://github.com/lavab https://github.com/lavab 2. We'll have Chrome/Firefox extensions for something similar to "signed binaries" 3. We offer the option to run the web client yourself (git clone https://github.com/lavab/web https://github.com/lavab/web && cd web && npm install && gulp && open "http://localhost:5000" http://localhost:5000") 4. We'll build native desktop and mobile clients. Hope this answers your question.
    - Procrastes 11y ago
      Native, or client-hosted javascript sounds workable. Server hosted Javascript cannot be secure even in theory (without a client-side plugin). I gave up on this problem when I shuttered Harpo Mail because of this and I am a US Citizen and realized I can't legally or ethically claim I won't turn you over to the Feds if they hold a gun to my head. It sounds like you are addressing those issues and more, and I wish you success.
      - simi_ 11y ago
        Thank you! :) Our servers and us are also based in Germany, which is a plus.
        e12e 11y ago
        How is it a plus that they're hosted in Germany? The German spy service are on record spying for the NSA, and of course only German citizens are protected by German law, so if anything, for users from the US, being hosted in Germany should be even worse than being hosted in the US (Assuming, the current slow, blow-back against the NSA goes anywhere). I don't really understand this fascination with hosting things outside of the US "for security" (from apparently, mostly US citizens). Personally I'm in Norway, where the secret police have been spying on "dissidents" (it used to be the "far" left, nominally the neo-nazis/fascists (although they missed the only terror attack, despite having a tip before the fact) -- now it's the "radical" Muslims (you know, a clearly defined threat to national security, aka "brown scary people")). But regardless of how one feels about using Stasi methods to help perpetuate and sustain illegal wars on the middle east -- one thing should be abundantly clear: Nowhere (AFAIK) does foreign citizens have any rights to not be spied on by local intelligence services. And of course all of NATO is working together on gathering it (along with Sweden, which Norwegian intelligence reportedly work closely with). All that said, while I think we should all work at taking back our respective governments, and strive for a better (more free) political environment -- I don't think the only measure for an email service should be "am I now safe from state-sponsored actors". In fact, I think that should actually be pretty low on the list. Use gpg, or give up. More significantly, if you can't do the work for a proper web-of-trust/key distribution and verification, you can't be secure (in the sense indicated above). I still think services like these are miles better than you-are-the-product, like gmail/outlook.com etc. Good luck on your service!
        pzduniak 11y ago
        From what I've been told, it's significantly harder to confiscate servers in Germany - but even if that somehow happens, all they would find on our servers is a bunch of encrypted blobs.
- tinco 11y ago
  What is your reaction to security professionals (such as tptacek) objecting to browser encryption? Do you take any specific measures to address the concerns that they have such as browser plugins being able to see decrypted keys, and man-in-the-middle attacks injecting javascript?
  - simi_ 11y ago
    We're a small team with limited resources, JS is the easiest medium to get started and ship MVP. Until we have native apps for most popular platforms, you have two options: (1) run the web client on your own machine, and use Lavaboom this way - if you trust your own computer, of course (2) install a Chrome/Firefox extension to have some proof that the code is the same as the one at github.com/lavab/web - this is still WIP on our end Signed native binaries are the best solution IMHO, we're aiming to get there for most major platforms, as I said.
    - tptacek 11y ago
      How does (2) actually work, given that almost any content element loaded onto the page can override what's in the .js file?
      - simi_ 11y ago
        > proof that the code is the same as the one at github.com/lavab/web Theoretically we can prove (via Chrome packaged apps, for example) that the code running on Lavaboom's servers (or locally if you run the web app yourself) is from our public repos. If the code doesn't do magic stuff like dynamically changing itself, and since we use TLS to deliver it, it should be impossible to maliciously alter what's running on the client side, unless we leverage some hypothetical unknown-yet browser-specific vulnerabilities(?). Also, network activity can be monitored, theoretically the users will be able to detect ~if~ when we start streaming their data to NSA servers. Unless you assume our server is completely compromised and we do the streaming ourselves. By the way, that's why I designed the system with the premise that we ourselves can't be trusted (e.g. haxorz pwnd us etc.) i.e. asymmetric encryption everywhere. Here's for instance some of my actual data (ignore the pre-refactoring messiness): https://gist.github.com/andreis/70c8f5bb1d811f6ac7db https://gist.github.com/andreis/70c8f5bb1d811f6ac7db PS: I'm not saying a web app are ideal for what we do, as I mentioned in another comment we started with it due to sheer pragmatism, and we're planning native apps (or at the very least cordova/electron "native" apps). I would really appreciate your thoughts on the matter.
- nyolfen 11y ago
  i tried filing a support ticket about this a couple of days ago and haven't heard back, but i'm unable to get my inbox to decrypt on my second computer. the computer i set the account up on works fine, but it just tells me that it doesn't have a private key when i try to look at my inbox on my laptop. i tried uploading the .json file that i guess is my keypair that downloaded when i set up the account, but it doesn't seem to do anything, just keeps saying no private key. chrome on ubuntu on both devices.
  - pzduniak 11y ago
    Sorry for no response to the ticket, we found quite a few bugs during integration of our support system and we have a ~200 queued tickets. Please create a new one directly on http://support.lavaboom.com/help_center http://support.lavaboom.com/help_center and I'll take care of your issue.
- e12e 11y ago
  As I've recently discovered[1], there appears to be ample room for a good xmpp service as well as for email. Any plans to host a jabber service? If you manage to handle distribution of gpg-keys, that'd be a way to bootstrap distribution/verification of OTR identities as well... [1] https://news.ycombinator.com/item?id=9546145 https://news.ycombinator.com/item?id=9546145
  - simi_ 11y ago
    We plan to build chat into Lavaboom, but we haven't figured out yet what's the best way to do it (and it's a _way_ long ahead, anyway). What you're saying makes a lot of sense and is definitely a possibility.
yc1010 11y ago
What exactly does "Zero-Access" mean?
- glibgil 11y ago
  Probably something like this http://zeroknowledgeprivacy.org/ http://zeroknowledgeprivacy.org/
  - floody-berry 11y ago
    Yeah, a made-up term that was ripped off from http://en.wikipedia.org/wiki/Zero-knowledge_proof http://en.wikipedia.org/wiki/Zero-knowledge_proof because it sounded high-tech, yet has nothing to do with ZKP and merely means "you encrypt everything client-side and we store binary blobs on the server for you".
    - yc1010 11y ago
      I see so this works similar to how blockchain.info site works in the browser, with the server used for encrypted backups and to retrieve blockchain data. Thanks for answering
      - pzduniak 11y ago
        We actually based the Lavaboom Sync functionality on blockchain.info's model - the private keys are encrypted using user's plaintext password, while the client only sends the password's hash to the server during authentication.
- simi_ 11y ago
  As glibgil says, it's called Zero Knowledge and it means we can't access your data because it's encrypted client-side. It was a no-brainer, since we already have your public key. We make key management easier by offering the option to enable Lavaboom Sync, basically your public and (encrypted) private keys stay on our server and get downloaded on login.
deleted 11y ago
[deleted]
drdaeman 11y ago
What's the point if email's still plaintext in transit?
- simi_ 11y ago
  Here's how Lavaboom works. I hope this will alleviate your worries about emails being sent as plaintext (for PGP users). 1. alice@lavaboom.com sends an email to bob@gmail.com Alice already has a keypair (generated automatically at registration), and Bob has one too. Alice adds Bob as a contact (or does nothing and is matched to Bob's key from a public key server), and sends him an email. The email contents + metadata is encrypted before they leave the Lavaboom email client, and are encrypted all the way to Bob. If Bob uses an email client with PGP support, then he can decrypt the email. 2. alice@lavaboom.com sends and email to zulu@lavaboom.com Same scenario as above, except that key exchange is done automatically for Lavaboom users (and emails don't leave our servers, making the process even more secure). 3. alice@lavaboom.com sends and email to carla@gmail.com Carla doesn't use PGP, so Alice's email needs to be sent as plaintext. However, before storing the email to the database, it is encrypted with Alice's key, and the plaintext version (residing in RAM) is deleted as soon as the mailer reports successful delivery. This way, only Alice has access to her data, and Lavaboom is Zero Knowledge in respect to email contents.
  - bradleybuda 11y ago
    This is a reasonable approach, but there's a weak link in public key exchange. If Lavaboom (or any other trusted third-party) is facilitating public key exchange, there's nothing preventing them from saying "DE:AD:BE:EF" is Bob's public key when in fact it belongs to Eve the attacker. Not to say that Lavaboom would do this maliciously, but they might be compelled to do so by a state actor or law enforcement. As a rule of thumb, a messaging system S can only be zero-knowledge if you have exchanged a secret or key with someone else outside of system S. See the HN discussion on iMessage: https://news.ycombinator.com/item?id=7315964 https://news.ycombinator.com/item?id=7315964
    - pzduniak 11y ago
brillenfux 11y ago
On Firefox 37.0.2 I got "Initialization failed" quickly after the "Authenticating" step. Also, I guess that wrecked my invitation code … Waiting for this to mature ;)
- simi_ 11y ago
  No problem, hit us up on hello@lavaboom.com for another invite code. That sounds bad, could you please describe your issue on http://web.lava.wtf http://web.lava.wtf ? Screenshots and console logs are appreciated! I can try to incentivise you to submit a bug report by promising an extra invite code once you submit an issue. :) (Just link this comment when you email hello@lavaboom.com)
unknownzero 11y ago
When I enter my info to reserve a username I never actually get the email with details the page mentions :(. Is this broken right now?
- pzduniak 11y ago
  Oops, it seems that someone broke the reservations during a website update - adding that to my TODO list.
  - unknownzero 11y ago
    Thanks for the reply, that it may take a while to receive the mail is probably useful information to throw on the reservations page until it's fixed if you expect that to take a while. Just a thought.
nullrouted 11y ago
Why is this any better than protonmail.ch?
- pzduniak 11y ago
  1) First of all, Lavaboom is fully opensource - ALL of our sourcecode is published on GitHub, so with enough efford you could download every piece of our setup and run it on your own server. 2) We support true end to end email encryption (it's not perfect, but a lot better than encrypting emails using some password in ProtonMail). Also you can manage all of your keys yourself if you wish, or keep your keychain encrypted on our server, just like in ProtonMail. 3) I'm definetely biased, but our stack is far better - ProtonMail uses PHP, which has a questionable reputation, meanwhile we use a static-typed language in the backend (Go). 4) Lavaboom is designed with hosted installations in mind - as soon as we sort out all the basic functionality of the "public version" (ie. hosted on lavaboom.com), we will start work on a self-hosted version which will make running it locally a lot easier - even on a Raspberry Pi :) 5) You can check all of our claims in the source code - we have nothing to hide! 5) Lavaboom to other providers emails use asymetric encryption. ProtonMail on the other hand... http://security.stackexchange.com/questions/58541/how-are-protonmail-keys-distributed http://security.stackexchange.com/questions/58541/how-are-pr... :) I might have repeated some points, but generally Lavaboom is a far more advanced product, which is in early stages on development. Right now I wouldn't recommend using Lavaboom for casual emailing, but I think that we will have all of ProtonMail's functionality during next two to three months and by the end of the year we should have a stable product with far more functionality for truly privacy conscious people.
  - fareastcoast 11y ago
    ProtonMail also isn't encrypting with a password, it's fully OpenPGP compliant using full length RSA keys. Also, how do we know Lavaboom is going to be around and stable? ProtonMail is financed by the Swiss government and developed at CERN.
duaneb 11y ago
How do you guys implement search?
- pzduniak 11y ago
  Right now we don't have any search at all, but we plan to generate search indexes locally in the background.

54 points by BillFranklin 11y ago

simi_ 11y ago

Lavaboom dev here, I'm happy to take questions. We're open source, mostly Angular and Go based: https://github.com/lavab https://github.com/lavab edit: just to point out, we're running a Indiegogo campaign! https://www.indiegogo.com/projects/lavaboom https://www.indiegogo.com/projects/lavaboom

fiatmoney 11y ago
"We use JavaScript. All encryption happens on your browser" How do you prevent the scenario of being forced to provide a poisoned client-side encryption payload, just like e.g. Hushmail was?
- simi_ 11y ago
  1. Our code is public. https://github.com/lavab https://github.com/lavab 2. We'll have Chrome/Firefox extensions for something similar to "signed binaries" 3. We offer the option to run the web client yourself (git clone https://github.com/lavab/web https://github.com/lavab/web && cd web && npm install && gulp && open "http://localhost:5000" http://localhost:5000") 4. We'll build native desktop and mobile clients. Hope this answers your question.
  - Procrastes 11y ago
    Native, or client-hosted javascript sounds workable. Server hosted Javascript cannot be secure even in theory (without a client-side plugin). I gave up on this problem when I shuttered Harpo Mail because of this and I am a US Citizen and realized I can't legally or ethically claim I won't turn you over to the Feds if they hold a gun to my head. It sounds like you are addressing those issues and more, and I wish you success.
    - simi_ 11y ago
      Thank you! :) Our servers and us are also based in Germany, which is a plus.
      - e12e 11y ago
        How is it a plus that they're hosted in Germany? The German spy service are on record spying for the NSA, and of course only German citizens are protected by German law, so if anything, for users from the US, being hosted in Germany should be even worse than being hosted in the US (Assuming, the current slow, blow-back against the NSA goes anywhere). I don't really understand this fascination with hosting things outside of the US "for security" (from apparently, mostly US citizens). Personally I'm in Norway, where the secret police have been spying on "dissidents" (it used to be the "far" left, nominally the neo-nazis/fascists (although they missed the only terror attack, despite having a tip before the fact) -- now it's the "radical" Muslims (you know, a clearly defined threat to national security, aka "brown scary people")). But regardless of how one feels about using Stasi methods to help perpetuate and sustain illegal wars on the middle east -- one thing should be abundantly clear: Nowhere (AFAIK) does foreign citizens have any rights to not be spied on by local intelligence services. And of course all of NATO is working together on gathering it (along with Sweden, which Norwegian intelligence reportedly work closely with). All that said, while I think we should all work at taking back our respective governments, and strive for a better (more free) political environment -- I don't think the only measure for an email service should be "am I now safe from state-sponsored actors". In fact, I think that should actually be pretty low on the list. Use gpg, or give up. More significantly, if you can't do the work for a proper web-of-trust/key distribution and verification, you can't be secure (in the sense indicated above). I still think services like these are miles better than you-are-the-product, like gmail/outlook.com etc. Good luck on your service!
        pzduniak 11y ago
        From what I've been told, it's significantly harder to confiscate servers in Germany - but even if that somehow happens, all they would find on our servers is a bunch of encrypted blobs.
tinco 11y ago
What is your reaction to security professionals (such as tptacek) objecting to browser encryption? Do you take any specific measures to address the concerns that they have such as browser plugins being able to see decrypted keys, and man-in-the-middle attacks injecting javascript?
- simi_ 11y ago
  We're a small team with limited resources, JS is the easiest medium to get started and ship MVP. Until we have native apps for most popular platforms, you have two options: (1) run the web client on your own machine, and use Lavaboom this way - if you trust your own computer, of course (2) install a Chrome/Firefox extension to have some proof that the code is the same as the one at github.com/lavab/web - this is still WIP on our end Signed native binaries are the best solution IMHO, we're aiming to get there for most major platforms, as I said.
  - tptacek 11y ago
    How does (2) actually work, given that almost any content element loaded onto the page can override what's in the .js file?
    - simi_ 11y ago
      > proof that the code is the same as the one at github.com/lavab/web Theoretically we can prove (via Chrome packaged apps, for example) that the code running on Lavaboom's servers (or locally if you run the web app yourself) is from our public repos. If the code doesn't do magic stuff like dynamically changing itself, and since we use TLS to deliver it, it should be impossible to maliciously alter what's running on the client side, unless we leverage some hypothetical unknown-yet browser-specific vulnerabilities(?). Also, network activity can be monitored, theoretically the users will be able to detect ~if~ when we start streaming their data to NSA servers. Unless you assume our server is completely compromised and we do the streaming ourselves. By the way, that's why I designed the system with the premise that we ourselves can't be trusted (e.g. haxorz pwnd us etc.) i.e. asymmetric encryption everywhere. Here's for instance some of my actual data (ignore the pre-refactoring messiness): https://gist.github.com/andreis/70c8f5bb1d811f6ac7db https://gist.github.com/andreis/70c8f5bb1d811f6ac7db PS: I'm not saying a web app are ideal for what we do, as I mentioned in another comment we started with it due to sheer pragmatism, and we're planning native apps (or at the very least cordova/electron "native" apps). I would really appreciate your thoughts on the matter.
nyolfen 11y ago
i tried filing a support ticket about this a couple of days ago and haven't heard back, but i'm unable to get my inbox to decrypt on my second computer. the computer i set the account up on works fine, but it just tells me that it doesn't have a private key when i try to look at my inbox on my laptop. i tried uploading the .json file that i guess is my keypair that downloaded when i set up the account, but it doesn't seem to do anything, just keeps saying no private key. chrome on ubuntu on both devices.
- pzduniak 11y ago
  Sorry for no response to the ticket, we found quite a few bugs during integration of our support system and we have a ~200 queued tickets. Please create a new one directly on http://support.lavaboom.com/help_center http://support.lavaboom.com/help_center and I'll take care of your issue.
e12e 11y ago
As I've recently discovered[1], there appears to be ample room for a good xmpp service as well as for email. Any plans to host a jabber service? If you manage to handle distribution of gpg-keys, that'd be a way to bootstrap distribution/verification of OTR identities as well... [1] https://news.ycombinator.com/item?id=9546145 https://news.ycombinator.com/item?id=9546145
- simi_ 11y ago
  We plan to build chat into Lavaboom, but we haven't figured out yet what's the best way to do it (and it's a _way_ long ahead, anyway). What you're saying makes a lot of sense and is definitely a possibility.

yc1010 11y ago

What exactly does "Zero-Access" mean?

glibgil 11y ago
Probably something like this http://zeroknowledgeprivacy.org/ http://zeroknowledgeprivacy.org/
- floody-berry 11y ago
  Yeah, a made-up term that was ripped off from http://en.wikipedia.org/wiki/Zero-knowledge_proof http://en.wikipedia.org/wiki/Zero-knowledge_proof because it sounded high-tech, yet has nothing to do with ZKP and merely means "you encrypt everything client-side and we store binary blobs on the server for you".
  - yc1010 11y ago
    I see so this works similar to how blockchain.info site works in the browser, with the server used for encrypted backups and to retrieve blockchain data. Thanks for answering
    - pzduniak 11y ago
      We actually based the Lavaboom Sync functionality on blockchain.info's model - the private keys are encrypted using user's plaintext password, while the client only sends the password's hash to the server during authentication.
simi_ 11y ago
As glibgil says, it's called Zero Knowledge and it means we can't access your data because it's encrypted client-side. It was a no-brainer, since we already have your public key. We make key management easier by offering the option to enable Lavaboom Sync, basically your public and (encrypted) private keys stay on our server and get downloaded on login.

deleted 11y ago

[deleted]

drdaeman 11y ago

What's the point if email's still plaintext in transit?

simi_ 11y ago
Here's how Lavaboom works. I hope this will alleviate your worries about emails being sent as plaintext (for PGP users). 1. alice@lavaboom.com sends an email to bob@gmail.com Alice already has a keypair (generated automatically at registration), and Bob has one too. Alice adds Bob as a contact (or does nothing and is matched to Bob's key from a public key server), and sends him an email. The email contents + metadata is encrypted before they leave the Lavaboom email client, and are encrypted all the way to Bob. If Bob uses an email client with PGP support, then he can decrypt the email. 2. alice@lavaboom.com sends and email to zulu@lavaboom.com Same scenario as above, except that key exchange is done automatically for Lavaboom users (and emails don't leave our servers, making the process even more secure). 3. alice@lavaboom.com sends and email to carla@gmail.com Carla doesn't use PGP, so Alice's email needs to be sent as plaintext. However, before storing the email to the database, it is encrypted with Alice's key, and the plaintext version (residing in RAM) is deleted as soon as the mailer reports successful delivery. This way, only Alice has access to her data, and Lavaboom is Zero Knowledge in respect to email contents.
- bradleybuda 11y ago
  This is a reasonable approach, but there's a weak link in public key exchange. If Lavaboom (or any other trusted third-party) is facilitating public key exchange, there's nothing preventing them from saying "DE:AD:BE:EF" is Bob's public key when in fact it belongs to Eve the attacker. Not to say that Lavaboom would do this maliciously, but they might be compelled to do so by a state actor or law enforcement. As a rule of thumb, a messaging system S can only be zero-knowledge if you have exchanged a secret or key with someone else outside of system S. See the HN discussion on iMessage: https://news.ycombinator.com/item?id=7315964 https://news.ycombinator.com/item?id=7315964
  - pzduniak 11y ago

brillenfux 11y ago

On Firefox 37.0.2 I got "Initialization failed" quickly after the "Authenticating" step. Also, I guess that wrecked my invitation code … Waiting for this to mature ;)

simi_ 11y ago
No problem, hit us up on hello@lavaboom.com for another invite code. That sounds bad, could you please describe your issue on http://web.lava.wtf http://web.lava.wtf ? Screenshots and console logs are appreciated! I can try to incentivise you to submit a bug report by promising an extra invite code once you submit an issue. :) (Just link this comment when you email hello@lavaboom.com)

unknownzero 11y ago

When I enter my info to reserve a username I never actually get the email with details the page mentions :(. Is this broken right now?

pzduniak 11y ago
Oops, it seems that someone broke the reservations during a website update - adding that to my TODO list.
- unknownzero 11y ago
  Thanks for the reply, that it may take a while to receive the mail is probably useful information to throw on the reservations page until it's fixed if you expect that to take a while. Just a thought.

nullrouted 11y ago

Why is this any better than protonmail.ch?

pzduniak 11y ago
1) First of all, Lavaboom is fully opensource - ALL of our sourcecode is published on GitHub, so with enough efford you could download every piece of our setup and run it on your own server. 2) We support true end to end email encryption (it's not perfect, but a lot better than encrypting emails using some password in ProtonMail). Also you can manage all of your keys yourself if you wish, or keep your keychain encrypted on our server, just like in ProtonMail. 3) I'm definetely biased, but our stack is far better - ProtonMail uses PHP, which has a questionable reputation, meanwhile we use a static-typed language in the backend (Go). 4) Lavaboom is designed with hosted installations in mind - as soon as we sort out all the basic functionality of the "public version" (ie. hosted on lavaboom.com), we will start work on a self-hosted version which will make running it locally a lot easier - even on a Raspberry Pi :) 5) You can check all of our claims in the source code - we have nothing to hide! 5) Lavaboom to other providers emails use asymetric encryption. ProtonMail on the other hand... http://security.stackexchange.com/questions/58541/how-are-protonmail-keys-distributed http://security.stackexchange.com/questions/58541/how-are-pr... :) I might have repeated some points, but generally Lavaboom is a far more advanced product, which is in early stages on development. Right now I wouldn't recommend using Lavaboom for casual emailing, but I think that we will have all of ProtonMail's functionality during next two to three months and by the end of the year we should have a stable product with far more functionality for truly privacy conscious people.
- fareastcoast 11y ago
  ProtonMail also isn't encrypting with a password, it's fully OpenPGP compliant using full length RSA keys. Also, how do we know Lavaboom is going to be around and stable? ProtonMail is financed by the Swiss government and developed at CERN.

duaneb 11y ago

How do you guys implement search?

pzduniak 11y ago
Right now we don't have any search at all, but we plan to generate search indexes locally in the background.