6 ms·

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,

by moxie 13y 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.

tnorthcutt 13y ago
Thanks for clearing that up for me.
rsync 13y ago
web hosted MUA < curses client over SSH [1] [1] like pine
- nzp 13y ago
  I agree for geeks, but not for "normal" people.
tlrobinson 13y 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.
- moxie 13y ago
  There's a huge difference between running your own mail server and running a mail client. Most people are not well positioned to run their own mail server. Mailpile is an MUA, not an MTA.
  - antocv 13y ago
    People werent well positioned to run their own web browser either. We can make it happen, if this new thing is so attractive people would will do it, just like they put up with Windows for several decades now. It could be a simple raspberry pi box that has all the stuff ready-made, just enter wifi credentials and whatever and run. The box has to be in white and silver because then who wouldnt want one? To show it off like a status symbol. A sleek little box in a corner, "my own email" people could say.
igravious 13y 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 :)
- DrewHintz 13y ago
  If your browser gets JavaScript crypto from webmail.example.com every time you visit webmail.example.com then there's nothing stopping webmail.example.com from serving malicious JavaScript crypto that steals your keys or unencrypted data. Even though the JavaScript runs locally, the code is supplied by webmail.example.com. There's a discussion of this and a few other issues here: http://www.matasano.com/articles/javascript-cryptography/ http://www.matasano.com/articles/javascript-cryptography/ JavaScript in web browsers also has a few other issues, such as side-channel timing attacks and the lack of control of memory.
  - igravious 13y ago
    Ahhh. I see. But of course, how dim of me. In that case, why do we trust e-commerce? Are we stupid to trust e-commerce? Am I right in saying though that if the javascript has been signed that the browser could trust it assuming the browser could trust webmail.example.com I mean, we all get our software from somewhere. Why should I trust a security update from Apple, Microsoft, or Canonical for instance ...
    - tptacek 13y ago
      E-commerce doesn't rely on Javascript cryptography. You generally don't trust code updates, which is one reason you do them infrequently; every time you update code there's an opportunity for someone who has corrupted the update process to take over your machine. A Javascript application might need to update itself several times per second across a single execution of itself.
saljam 13y 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.
- thwest 13y ago
  One time I hacked chromium to skip the socket and send the HTTP directly to the embedded python wsgi app. In the end we couldn't use it because we needed some 64 bit only code running behind the wsgi and chromium only builds 32 bit on windows. Not that it would really be ideal either. Your app is too easily confused for a legit chromium window.
chacham15 13y 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.
- simonw 13y ago
  Surely the hashing solution you propose can only be implemented as an enhancement to browsers? If you have decentralised "verifiers" how can you be sure that the version they most recently verified is the same code as your browser just downloaded? I'm not convinced the "webapp crypto problem" can be solved without changes to browsers.
  - ds9 13y ago
    Why not a plugin? Imagine this scenario. You get a plugin from your distro's repository; you have encrypted, sig-checking, hash-checking mechanism in apt or rpm or whatever. It is open source/Libre, maintained and audited by competent crypto people, uses well-vetted mechanisms in the code, etc.. And what this does is run native code to encrypt your message, after prompting for a passphrase to unlock your private key. It provides an editing window so plaintext won't go into the browser. Then after editing, you encrypt, and the plugin pastes the encrypted text, in, say, ASCII form, into the text field in the webmail application. The correspondent of course has the same plugin and uses it for decryption. You exchange public keys with your correspondents by a side channel. (Edit: Obviously, you can do this today, minus the GUI; it's easy enough to run a GPG command, use a text editor, paste manually) This would be a non-starter on vendor-captive smartphones and tablets, of course, and proprietary OS, as such systems are fundamentally unsecurable. But it might be viable for laptops, desktops and anywhere you can have root with Linux or BSD. The metadata problem is much harder.

by moxie 13y ago

tnorthcutt 13y ago

Thanks for clearing that up for me.

rsync 13y ago

web hosted MUA < curses client over SSH [1] [1] like pine

nzp 13y ago
I agree for geeks, but not for "normal" people.

tlrobinson 13y 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.

moxie 13y ago
There's a huge difference between running your own mail server and running a mail client. Most people are not well positioned to run their own mail server. Mailpile is an MUA, not an MTA.
- antocv 13y ago
  People werent well positioned to run their own web browser either. We can make it happen, if this new thing is so attractive people would will do it, just like they put up with Windows for several decades now. It could be a simple raspberry pi box that has all the stuff ready-made, just enter wifi credentials and whatever and run. The box has to be in white and silver because then who wouldnt want one? To show it off like a status symbol. A sleek little box in a corner, "my own email" people could say.

igravious 13y 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 :)

DrewHintz 13y ago
If your browser gets JavaScript crypto from webmail.example.com every time you visit webmail.example.com then there's nothing stopping webmail.example.com from serving malicious JavaScript crypto that steals your keys or unencrypted data. Even though the JavaScript runs locally, the code is supplied by webmail.example.com. There's a discussion of this and a few other issues here: http://www.matasano.com/articles/javascript-cryptography/ http://www.matasano.com/articles/javascript-cryptography/ JavaScript in web browsers also has a few other issues, such as side-channel timing attacks and the lack of control of memory.
- igravious 13y ago
  Ahhh. I see. But of course, how dim of me. In that case, why do we trust e-commerce? Are we stupid to trust e-commerce? Am I right in saying though that if the javascript has been signed that the browser could trust it assuming the browser could trust webmail.example.com I mean, we all get our software from somewhere. Why should I trust a security update from Apple, Microsoft, or Canonical for instance ...
  - tptacek 13y ago
    E-commerce doesn't rely on Javascript cryptography. You generally don't trust code updates, which is one reason you do them infrequently; every time you update code there's an opportunity for someone who has corrupted the update process to take over your machine. A Javascript application might need to update itself several times per second across a single execution of itself.

saljam 13y 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.

thwest 13y ago
One time I hacked chromium to skip the socket and send the HTTP directly to the embedded python wsgi app. In the end we couldn't use it because we needed some 64 bit only code running behind the wsgi and chromium only builds 32 bit on windows. Not that it would really be ideal either. Your app is too easily confused for a legit chromium window.

chacham15 13y 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.

simonw 13y ago
Surely the hashing solution you propose can only be implemented as an enhancement to browsers? If you have decentralised "verifiers" how can you be sure that the version they most recently verified is the same code as your browser just downloaded? I'm not convinced the "webapp crypto problem" can be solved without changes to browsers.
- ds9 13y ago
  Why not a plugin? Imagine this scenario. You get a plugin from your distro's repository; you have encrypted, sig-checking, hash-checking mechanism in apt or rpm or whatever. It is open source/Libre, maintained and audited by competent crypto people, uses well-vetted mechanisms in the code, etc.. And what this does is run native code to encrypt your message, after prompting for a passphrase to unlock your private key. It provides an editing window so plaintext won't go into the browser. Then after editing, you encrypt, and the plugin pastes the encrypted text, in, say, ASCII form, into the text field in the webmail application. The correspondent of course has the same plugin and uses it for decryption. You exchange public keys with your correspondents by a side channel. (Edit: Obviously, you can do this today, minus the GUI; it's easy enough to run a GPG command, use a text editor, paste manually) This would be a non-starter on vendor-captive smartphones and tablets, of course, and proprietary OS, as such systems are fundamentally unsecurable. But it might be viable for laptops, desktops and anywhere you can have root with Linux or BSD. The metadata problem is much harder.