End-to-End Encryption Plugin for Yahoo Mail | Hacker News Reader

End-to-End Encryption Plugin for Yahoo Mail

yahoo.tumblr.com

228 pointsdanielweber44 comments

Little known fact: Google's End-to-end encryption extension already works on any site. It is not limited to Gmail. In fact it's not limited to webmail either. If a PGP blob is present in a web page, End-to-end can decrypt it. If a text input area is present in a web page, End-to-end can encrypt it.

I have no idea how to get that extension or how to install it.

Is there some simple guide?

edit: all I see here

https://github.com/google/end-to-end

We’re releasing this code to enable community review; it is not yet ready for general use

They have a Wiki that has build/install instructions: https://github.com/google/end-to-end/wiki/Build-instructions.

Basically, clone the Git repo then do:

  ./do.sh install_deps
  ./do.sh build_extension

This results in an extension folder that can be installed via Chrome's developer mode.

Disclaimer: not affiliated in any way and never used it myself

That is the way I built it. I wanted to add that java is required.

Interesting that they've had a vulnerability reward program since June 2014. I wonder how that's getting on

http://googleonlinesecurity.blogspot.com/2014/06/making-end-...

They provided an update last December[1] and stated that two rewards have been given. The same update is also interesting because it mentioned the migration from Google Code to Github (three months ago!). The blog post talked about Yahoo! contribution to the project too...

[1] http://googleonlinesecurity.blogspot.com/2014/12/an-update-t...

A Windows build environment is not supported.

Wonder what they thougt there? Windows is where the majority of users are, it's where the people who can't (or don't want to) use command line tools for encryption are.

Why would you even approach this from a Linux-first angle? I'd understand if it was because the developers are typically Linux users and they want it thuroughly tested before shipping a user friendly version (i.e chrome ext for windows).

It's not ready for consumers yet. The end result will be a Chrome extension anyway.

Littler-known fact: if you are serious about protecting that message, then web based email can't really do it.

So long as the server has access to your plaintext as you compose it, the security is compromised and a third party has it. And then if the recipient views the plaintext from a browser...

If you want the email to be secret, it must be in it's encrypted form before the browser even knows about it ... but at that point, why not just use a different, well vetted client program for email?

> but at that point, why not just use a different, well vetted client program for email?

Anyone have any names?

Mutt and Thunderbird come to mind.

GPG in Mutt is fantastically well integrated.

Now, of course, you have to get used to Mutt first :)

Thunderbird with Enigmial also works quite well. I use it everyday.

Clawsmail as well :)

Whiteout.io is a chrome app for email, plus an android app with key-synch between the two. It's still early stages, so it has some issues (like indexing all your emails, since forever, and overheating your computer). But it's very promising.

Most people want to continue using webmail though. That's why Mailvelope is so awesome. Continue using webmail, but just have an extra button added which opens up an editor with a bit "encrypt" button. Pretty easy, and pretty safe.

There's also protonmail.ch tutanota.de and several others in early stages.

https://crypto.cat/

I thought that the google thing would be implemented along the lines of the above service. I didn't realise the server still has access to the plaintext as it it composed?

The way these end to end plugins work, the website never has access to the plaintext message, it all goes through your browser extension first.

What GP is saying is not directly correct, but if the third-party service is compromised they could force you to leak the unencrypted message?

More than that if the third-party service is compromised they can MiTM your encrypted communications anyways.

No, it's encrypted client-side in the extension. A MITM would only see the already encrypted message that your email provider would have seen.

That wasn't the point I was making - you're still relying on Yahoo providing the public key which corresponds to a given email-address, nothing prevents Yahoo (or whichever third-party service you use) from decoding your messages under those conditions.

You're also relying that the third-party extension used for encryption hasn't been tampered with on their end.

Sorry, I may have misunderstood based on which kind of MITM you were talking about here :)

For the points you bring up, at least in the current nerfed extension they aren't really an issue. Key exchange does not happen through the extension or through yahoo, it has to happen out of band. In addition, since this is just the developer preview, AFAIK there is no extension distribution except through github (and so no updates to auto-download). You have to build and install the extension yourself.

Key exchange and extension verification are still two difficult remaining problems, but they are hopefully not insurmountable.

It's in an iframe the page has no access to.

(please read about things before taking it on yourself to educate others...)

Sure, so long as a) the extension uses a sandboxed one, and b) you can assume your browser and c) extension implementation don't leak iframe information.

It just seems like an unnecessary and avoidable risk.

It's a cross-domain iframe, so there is no access to it by the page.

Security is subject to browser exploits, that's true, but that has nothing to do with what you were saying above.

Because it's hard to MITM that :P

Yeah, I got the feeling this only works with Yahoo Mail. That's pretty disappointing. Is it really that much harder to make it work across at least the big email providers, while still being able to remove that setting-up the private key and sharing the public key confusion that people get when using PGP? Or is it more of a political/collaboration issue (the big companies don't want to work together on this)?

Rather to compare E2E with Mac GpgTools, I'd try to compare it with https://www.mailvelope.com/ which is a much better comparison since both are addons for browsers.

Mailvelope works both on Firefox and Chrome (ironically, the Yahoo plugin seems to only have Chrome support at the moment) and is actually even nicer to use (read: seamless) than E2E IMO.

Yeah, I use mailvelope with my close friends and family. It's not yet easy enough for my parents generation to "get it" but if it's set up for them they can muster through it.

The problem with plugins though is that very few people go out of their way to install browser plugins. Having an integrated option is way more useful. So some people have to encrypt/decrypt in-browser using Javascript (like, how tutanota and protonmail do it, or like whiteout.io does, or like anybody can do now using the keynote.io API). I know it's not ideal, but it is way better than nothing. It won't stop the NSA, but it will stop hackers, email leakers, doxxers, and big-data email-mining algorithms.

Not aware of this, looks great! Thanks.

Can someone give an explanation of how this works?

In order to get this to be seamless, I would guess that this only works when you are sending from one yahoo account to another one correct? Unless they have found a clever way to share the public keys.

It looks like they forked Google's end-to-end Chrome extension. Best place to look would probably be the docs for google's e2e. https://github.com/google/end-to-end/wiki

Yahoo Paranoids Engineering Director for end-to-end here.

Today our extension works as a developer only demo, and no Yahoo keyserver service is online yet. If our toy keyserver code didn't make it into this release, you will see it very soon and will be able to experiment.

We released the source so we can solicit security feedback early, and can keep all security and privacy critical parts of this product in the open. No "just trust us" now or in the future.

Along those lines, we will work with industry peers to build public key registry software that interoperates with other federated providers, is open source, and is transparent in the cryptographic sense. I.e. Yahoo and Google users should be able to send encrypted email to one another with ease, and if either company was forced to lie about the public keys of our respective users we would be caught because math.

There's a lot more in the works, and we have many challenges to overcome to make this generally usable. In addition to the key server, there's not unnecessarily breaking existing mail features, multi-device issues, search over encrypted content w/o providers being able to read it, and mobile support to start.

If you know anyone with the skills and motivation to make strong, usable encryption available at internet scale we'd love to listen, collaborate, or hire. :)

This is very cool. Thank you for working on it.

I do know a team whom you should work with: keybase.io

Keybase.io have an early-level product which would help with your keyserver issue. It has a CORS-enabled API, a commandline tool, an online interface for encrypting, signing, verifying, etc. and a "ring of trust" tool that follows the modern social network model (where, you can "track" somebody and it auto-signs their keys each time they upgrade.

Except that we cannot verify that you actually deploy the "open" code. It's obviously commendable that you do development in the open, and have people review the work you do. But there is no way for us to know that you don't run /addNSAbackdoor.sh in your deploy script for key parts of your infrastructure.

There is already published docs that show Yahoo is/was part of Prism since 2008: http://www.wired.com/2014/09/feds-yahoo-fine-prism/

All encryption runs clientside. The whole point of end-to-end is that you don't have to care about who the message passes through.

Your actual worries at this point are the key exchange (impersonation) and extension distribution.

The first is very hard to get right without alienating a large number of potential users, the second seems perfectly possible to have verified but seems like it's going to require some kind of changes in the Chrome extension system.

It doesn't have to pass through anything but if the '/addNSAbackdoor.sh' script just adds a routine to the code that adds the Public Key of an NSA owned key-pair before the encryption process, then the NSA can pick it up from any Internet-tap they have and decrypt it.

Except that this runs locally, so if you're worried about that, you can build it yourself.

Maybe Its time to introduce reproducible buulds to the JavaScript word? So that we can prove that the minified version is the same as the source.. Or just release the code as a nonminified AGPL set of ES6 files. With the coming of http2 it's going to be less of a problem But I still think we need to think of an out of band way to verify trust. Just like I can verify that my install of gpg or tails is legit

You're in luck! There's a working group called "Subresource Integrity" that's developing a way to allow websites to restrict a resource (including javascript files) to a defined hash.

http://www.w3.org/TR/SRI/

This is a step in the right direction for embedding external resources. It'd remove CDNs as an attack vector (once it's rolled out everywhere).

It'd be great to come up with some kind of way to also tell the client what resources are expected, and if a new one is loaded (e.g. <iframe src="http://dangerous.malware.com"></iframe>) the client would not even connect to it.

When you release the keyserver, please make sure that CORS is enabled. I'd love to add it to PublicKey.js[1]. Even better would be for it to gossip to the SKS pool. That way, gpg --recv-key would work to get Yahoo users' public keys.

[1]: https://github.com/diafygi/publickeyjs

It is worth noting that the Yahoo! devs do not promise OpenPGP (RFC 4880) compatibility in the future.

now take my public and private key Yahoo!

Reply on news.ycombinator.com