Re: [liberationtech] Mailvelope: OpenPGP Encryption for Webmail
----- Forwarded message from Uncle Zzzen <unclezzzen@gmail.com> -----
Please write your input here https://github.com/toberndo/mailvelope/issues/14#issuecomment-11279951 github discussion about this issue I am really interested if it's solvable in an easy way On Wed, Dec 12, 2012 at 8:51 AM, Eugen Leitl <eugen@leitl.org> wrote:
----- Forwarded message from Uncle Zzzen <unclezzzen@gmail.com> -----
From: Uncle Zzzen <unclezzzen@gmail.com> Date: Wed, 12 Dec 2012 12:38:40 +0700 To: liberationtech <liberationtech@lists.stanford.edu> Subject: Re: [liberationtech] Mailvelope: OpenPGP Encryption for Webmail Reply-To: liberationtech <liberationtech@lists.stanford.edu>
The reason why FireGPG no longer ships with tails is that the DOM of a web app is not a safe place for plaintext https://tails.boum.org/doc/encryption_and_privacy/FireGPG_susceptible_to_dev... Any architecture where plaintext is stored inside a web app's DOM is dangerous. Especially a webmail app that can be expected to save drafts, but not only. Web apps can be MITMed, XSSed, etc. If it came via the web, it's a suspect.
I'd expect a crypto add-on to only accept plaintext (and other sensitive) information via separate GUI that can only be launched manually (not via javascript in an app's DOM) and has a hard-to-imitate look-and-feel (to discourage phishing). The only communication between this add-on and the rest of the browser should be via the clipboard. Users who can't handle copy/paste shouldn't be trusted with a key pair :)
From what I see at the http://www.mailvelope.com/ slide-show, it seems to provide even more shooting-yourself-in-the-leg firepower than FireGPG.
On Wed, Dec 12, 2012 at 3:21 AM, Nadim Kobeissi <nadim@nadim.cc> wrote:
Cryptocat is a local browser plugin served over SSL, installed locally, loads/executes no external code, and communicates only via SSL. It does not rely on server integrity with regards to these parameters.
Regarding Mailvelope b does its operation depend on the Gmail DOM? What happens if the Gmail DOM is modified, can that be used to damage the integrity of Mailvelope operations? There's a reason Cryptocat operates in its own browser tab separate from other sites.
NK
On 2012-12-11, at 6:54 PM, Andy Isaacson <adi@hexapodia.org> wrote:
On Mon, Dec 10, 2012 at 10:07:23PM +0000, StealthMonger wrote:
"Fabio Pietrosanti (naif)" <lists@infosecurity.ch> writes:
for whose who has still not see that project, i wanted to send a notice about MailVelope, OpenPGP encryption for webmail: http://www.mailvelope.com
It's a client-side, plug-in based (similar to CryptoCat), OpenPGP email encryption plugin available for Chrome and Firefox.
To compare it with CryptoCat is unfair to MailVelope. As I understand things, CryptoCat has an ongoing reliance on server integrity. On the other hand, MailVelope is self-contained once securely installed,
I'm not sure why you claim that. It was true for Cryptocat v1 which was a browser app and could be compromised at any time with new JS from a compromised server. Cryptocat v2 is a downloadable + installable plugin which at least doesn't immediately execute code served to it.
In both the JS and plugin versions, Cryptocat (with uncompromised code) does not depend on server integrity for message confidentiality.
Now, both CryptoCat and MailVelope probably have an upgrade vulnerability where a compromised server can tell the app "there's a new version available, plese ask the user to install it". And since the compromised server could refuse to provide service to the secure version of the app, there's a powerful functional reason for the user to accept the upgrade.
Ah, perhaps you're referring to the fact that MailVelope layers on top of another server (Gmail) for its transport layer, rather than depending on a "MailVelope server" which could selectively deny service to the uncompromised version of the product. In that respect, MailVelope might be more secure-by-design than Cryptocat.
-andy -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
-- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
-- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
Please write your input here
https://github.com/toberndo/mailvelope/issues/14#issuecomment-11279951
github discussion about this issue
I am really interested if it's solvable in an easy way
On Wed, Dec 12, 2012 at 8:51 AM, Eugen Leitl <eugen@leitl.org> wrote:
----- Forwarded message from Uncle Zzzen <unclezzzen@gmail.com> -----
From: Uncle Zzzen <unclezzzen@gmail.com> Date: Wed, 12 Dec 2012 12:38:40 +0700 To: liberationtech <liberationtech@lists.stanford.edu> Subject: Re: [liberationtech] Mailvelope: OpenPGP Encryption for Webmail Reply-To: liberationtech <liberationtech@lists.stanford.edu>
The reason why FireGPG no longer ships with tails is that the DOM of a web app is not a safe place for plaintext
https://tails.boum.org/doc/encryption_and_privacy/FireGPG_susceptible_to_dev... stating_attacks/
Any architecture where plaintext is stored inside a web app's DOM is dangerous. Especially a webmail app that can be expected to save drafts, but not only. Web apps can be MITMed, XSSed, etc. If it came via the web, it's a suspect.
I'd expect a crypto add-on to only accept plaintext (and other sensitive) information via separate GUI that can only be launched manually (not via javascript in an app's DOM) and has a hard-to-imitate look-and-feel (to discourage phishing). The only communication between this add-on and the rest of the browser should be via the clipboard. Users who can't handle copy/paste shouldn't be trusted with a key pair :)
From what I see at the http://www.mailvelope.com/ slide-show, it seems to provide even more shooting-yourself-in-the-leg firepower than FireGPG.
On Wed, Dec 12, 2012 at 3:21 AM, Nadim Kobeissi <nadim@nadim.cc> wrote:
Cryptocat is a local browser plugin served over SSL, installed locally, loads/executes no external code, and communicates only via SSL. It does not rely on server integrity with regards to these parameters.
Regarding Mailvelope b does its operation depend on the Gmail DOM? What happens if the Gmail DOM is modified, can that be used to damage the integrity of Mailvelope operations? There's a reason Cryptocat operates in its own browser tab separate from other sites.
NK
On 2012-12-11, at 6:54 PM, Andy Isaacson <adi@hexapodia.org> wrote:
On Mon, Dec 10, 2012 at 10:07:23PM +0000, StealthMonger wrote:
"Fabio Pietrosanti (naif)" <lists@infosecurity.ch> writes:
for whose who has still not see that project, i wanted to send a notice about MailVelope, OpenPGP encryption for webmail: http://www.mailvelope.com
It's a client-side, plug-in based (similar to CryptoCat), OpenPGP email encryption plugin available for Chrome and Firefox.
To compare it with CryptoCat is unfair to MailVelope. As I understand things, CryptoCat has an ongoing reliance on server integrity. On the other hand, MailVelope is self-contained once securely installed,
I'm not sure why you claim that. It was true for Cryptocat v1 which was a browser app and could be compromised at any time with new JS from a compromised server. Cryptocat v2 is a downloadable + installable
What I now implemented and put as a github pull request to the original project: the extension user can now use a chrome pop-up for writing the mail (not meaning pop-up as an annoying ad window, but as a chrome extension window that displays when you click on the extension icon) AFAIK, no javascript can display such an extension pop-up and also can't intercept anything. I also added a big red warning, instructing to open the pop-up, that shows whenever the original encryption is triggered from inside the regular webmail DOM (it's still possible to use the extension is "unsafe" way with mail provider intercepting, but you have to ignore the warning). Let's hope Thomas accepts those changes and adds them to the main extension :) K On Wed, Dec 12, 2012 at 2:31 PM, Karel Bmlek <kb@karelbilek.com> wrote: plugin
which at least doesn't immediately execute code served to it.
In both the JS and plugin versions, Cryptocat (with uncompromised code) does not depend on server integrity for message confidentiality.
Now, both CryptoCat and MailVelope probably have an upgrade vulnerability where a compromised server can tell the app "there's a new version available, plese ask the user to install it". And since the compromised server could refuse to provide service to the secure version of the app, there's a powerful functional reason for the user to accept the upgrade.
Ah, perhaps you're referring to the fact that MailVelope layers on top of another server (Gmail) for its transport layer, rather than depending on a "MailVelope server" which could selectively deny service to the uncompromised version of the product. In that respect, MailVelope might be more secure-by-design than Cryptocat.
-andy -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
-- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
-- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
participants (2)
-
Eugen Leitl -
Karel Bílek