[liberationtech] Mailvelope: OpenPGP Encryption for Webmail

Nadim Kobeissi nadim at nadim.cc
Tue Dec 11 12:21:19 PST 2012


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 — 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




More information about the liberationtech mailing list