[liberationtech] Mailvelope: OpenPGP Encryption for Webmail

[Karel Bílek]

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 at leitl.org> wrote:
> ----- Forwarded message from Uncle Zzzen <unclezzzen at gmail.com> -----
>
> From: Uncle Zzzen <unclezzzen at gmail.com>
> Date: Wed, 12 Dec 2012 12:38:40 +0700
> To: liberationtech <liberationtech at lists.stanford.edu>
> Subject: Re: [liberationtech] Mailvelope: OpenPGP Encryption for Webmail
> Reply-To: liberationtech <liberationtech at 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_devastating_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 at 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 at hexapodia.org> wrote:
>>
>> > On Mon, Dec 10, 2012 at 10:07:23PM +0000, StealthMonger wrote:
>> >> "Fabio Pietrosanti (naif)" <lists at 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