[liberationtech] Mailvelope: OpenPGP Encryption for Webmail

Wed Dec 12 16:33:54 PST 2012

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 at karelbilek.com> wrote:
> 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_deva
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 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