yahooarchive / end-to-end Goto Github PK

If we want to avoid the need for manual recovery in case a profile update makes it to the keyserver but the reply does not make it back, the client should retry the update until it gets a definitive response, EVEN IF the client has not been running continuously since it first issued the update. Not doing this can cause the affected client to sign messages using the previous PGP key while its contacts see the results of an update whose reply got list (and thus they reject the signatures).

from @dougdeperry:

Bug Description:
It is possible to spoof a decrypted message using an image or by creating a similar-looking frameset in HTML (see attachments). This could potentially confuse a user into believing that the message they are receiving is encrypted and therefore to be trusted more than a plaintext email. Without much further extrapolation, the user could believe that replying to this message would automatically be encrypted.

Reproduction Steps:
To reproduce this bug you could encrypt a message to yourself and take a screenshot of it once it is decrypted - then copy/paste it into an email to the victim. Injecting the frameset HTML is slightly more difficult:

In a non-encrypted email, right-click in the message body and “inspect element”
In dev tools window expand

and tags of highlighted element
Right-click
and select “Edit as HTML”
Paste the frameset code directly after

Click outside the edit box to save the results
See the frameset appear in the message body, manually tweak font size as necessary
Send the email
Mitigation:
Consider moving encrypted email indicators outside the message body (such as the current location of the lock icon) so that it is more difficult to spoof.

When replying an email in Yahoo Mail using end-to-end encryption, it shows a "ASCII Armor not found" error.

Screenshot

It is a good idea to regenerate public keys every once in a while. Previously, the cumbersome nature of PGP web of trust certification has kept people from doing this as frequently as possible. With a certifying keyserver, this should no longer be an issue. Therefore, it would make sense to (eventually) have a specialized facility for performing a transition from one key to another. This would involve.

1. Adding a a new PGP public key to the keyserver profile
2. Setting the previous one to expire soon.
3. Waiting for outstanding email (signed under the old key) to be delivered.
4. Removing the old public key from the profile
5. Possibly waiting some more until it is believed that all mail encrypted to the old key has been received.
6. Securely erasing the old key.

When sending a message in reply to a signed-and-encrypted message, a "Good signature from" notification appears. This is confusing and not very useful.

We have a pull request internally that merges important changes from Google end-to-end since we forked (sometime in November/December), so this is in progress. Long-term we should try have a build task that does this periodically.

The items to be deprecated have been reviewed and approved by our "consulting cryptographers," Payman Mohassel and Juan Garay of Yahoo Labs.

Support removed

Tag 9 packets. Yahoo and Google have both already deprecated and removed support for Tag 9 (symmetrically encrypted) packets.

These packets provide unauthenticated encryption and, if supported, can be used in a downgrade attack for senders who only use SEIPD packets. See [encrux][encrux] for details.

ASAP

V3 public keys. Yahoo and GnuPG (as of version 2.1) have both already deprecated V3 public keys for any use. We recommend that other implementations do the same.

By May 1, 2015

Yahoo has deprecated, and intends to disable support for all uses, of the following algorithms specified for use with OpenPGP v4:

• Asymmetric algorithms, unless > 3070 bit key length: RSA-ES, ELG-E.
• Asymmetric algorithms, generally: RSA-E, RSA-S, DSA
• Symmetric cipher algorithms: IDEA, TDES, CAST5, Blowfish, Twofish
• Compression algorithms: ZLIB (the format provides no benefits over DEFLATE,
  and is more malleable)
• Hash algorithms: MD5, SHA-1, RIPEMD160, SHA-2-224

We do not, at present, support any of the CAMELLIA algorithms or Bzip2. It is unlikely that we will do so in future.

By September 1, 2015

Inconsistent combinations of primitives. In particular, it is likely that we will not support RFC 6637 keys or packets unless they conform to the 128-bit or 192-bit subprofiles specified in that document. (End-to-End does not at present support P-521, but if we add support for curves over that field, we would support an analogous "256-bit" subprofile.)

AES-128. The efficiency of multi-target attacks leaves no safety margin for cryptanalysis. The performance difference between AES-128 and AES-256 on typical messages is negligible.

Eventually

Finally, other things that may eventually result in messages or keys being treated as invalid:

• A published public key that is more than 1 year old. (This is mainly taken care of by requiring > 3070 bit RSA keys...)
• Signature by a public key which has ever signed a message or key using MD-5 or SHA-1
• Any literal data packet tag that is unusually formatted, or contains a non-zero-length subpart
• Any compressed data packet using a compression method other than algorithm 0 (uncompressed)

dougdeperry:

When importing keys, the UI appears to give you the ability to choose individual keys to import, but when you do this and attempt to import, a popup warns you to verify all keys and will not let you continue. Clicking “Select All” (which doesn't really look like a hyperlink) selects all keys and then the import will work successfully.

This is being worked on internally but needs more testing before open sourcing. "Watch this space", as the marketers say.

Someone reported it was annoying that e2e tries to encrypt every message when the recipient has a key.

We can actually get the user's active ymail account from a local javascript variable in Yahoo mail if they have the page open and are logged in. This is probably better since then we won't have to use the chrome.cookies permission.

e2ebind_test and composeglass_test fail sometimes with these errors in Chrome stable:

Unit Test of e2e.ext.e2ebind [FAILED]
localhost:8000/src/javascript/crypto/e2e/extension/helper/e2ebind_test.html
15 of 15 tests run in 563ms.
14 passed, 1 failed.
38 ms/test. 171 files loaded.
ERROR in testAutoInstallGlass [Waiting for glass to be installed]
Missing a call to getDraft
Expected: 1 but was: 0
> (unknown)
> (unknown)
> goog.testing.Mock.$throwException at http://localhost:8000/javascript/closure/testing/mock.js:535:24
> goog.testing.StrictMock.$verify at http://localhost:8000/javascript/closure/testing/strictmock.js:119:12
> anonymous at http://localhost:8000/javascript/closure/testing/mockcontrol.js:91:7
> Array.forEach
> Object.goog.array.forEach at http://localhost:8000/javascript/closure/array/array.js:203:43
> goog.testing.MockControl.$verifyAll at http://localhost:8000/javascript/closure/testing/mockcontrol.js:90:14
> anonymous at http://localhost:8000/javascript/crypto/e2e/extension/helper/e2ebind_test.js:216:17
> anonymous at http://localhost:8000/javascript/crypto/e2e/extension/testingstubs.js:32:5
> testAutoInstallGlass at http://localhost:8000/javascript/crypto/e2e/extension/helper/e2ebind_test.js:215:10
> goog.testing.TestCase.Test.execute at http://localhost:8000/javascript/closure/testing/testcase.js:1293:12
> goog.testing.AsyncTestCase.doExecute_ at http://localhost:8000/javascript/closure/testing/asynctestcase.js:878:19
> goog.testing.AsyncTestCase.callTopOfStackFunc_ at http://localhost:8000/javascript/closure/testing/asynctestcase.js:756:10
> goog.testing.AsyncTestCase.pump_ at http://localhost:8000/javascript/closure/testing/asynctestcase.js:805:16
> goog.testing.AsyncTestCase.runTests at http://localhost:8000/javascript/closure/testing/asynctestcase.js:508:8
> goog.testing.TestRunner.execute at http://localhost:8000/javascript/closure/testing/testrunner.js:270:19

Unit Test of e2e.ext.ui.ComposeGlass [FAILED]
localhost:8000/src/javascript/crypto/e2e/extension/ui/glass/composeglass_test.html
8 of 8 tests run in 1948ms.
6 passed, 2 failed.
244 ms/test. 0 files loaded.
ERROR in testRenderAndImportKey [Waiting for keys to be imported]
Expected <test 4,[email protected]> (Array) but was <test 4> (Array)
: Expected 2-element array but got a 1-element array
> _assert at http://localhost:8000/javascript/closure/testing/asynctestcase.js:634:26
> assertObjectEquals at http://localhost:8000/javascript/closure/testing/asserts.js:735:28
> assertArrayEquals at http://localhost:8000/javascript/closure/testing/asserts.js:818:63
> anonymous at http://localhost:8000/javascript/crypto/e2e/extension/ui/glass/composeglass_test.js:254:37
> anonymous at http://localhost:8000/javascript/crypto/e2e/extension/testingstubs.js:32:5
> anonymous at http://localhost:8000/javascript/crypto/e2e/extension/ui/glass/composeglass_test.js:252:12
> anonymous at http://localhost:8000/javascript/crypto/e2e/extension/testingstubs.js:32:5
> testRenderAndImportKey at http://localhost:8000/javascript/crypto/e2e/extension/ui/glass/composeglass_test.js:250:10
> goog.testing.TestCase.Test.execute at http://localhost:8000/javascript/closure/testing/testcase.js:1293:12
> goog.testing.AsyncTestCase.doExecute_ at http://localhost:8000/javascript/closure/testing/asynctestcase.js:878:19
> goog.testing.AsyncTestCase.callTopOfStackFunc_ at http://localhost:8000/javascript/closure/testing/asynctestcase.js:756:10
> goog.testing.AsyncTestCase.pump_ at http://localhost:8000/javascript/closure/testing/asynctestcase.js:805:16

ERROR in testRenderWithMissingRecipient [Waiting for keys to be imported]
Missing a call to insertMessageIntoPage_
Expected: 1 but was: 0
> (unknown)
> (unknown)
> goog.testing.Mock.$throwException at http://localhost:8000/javascript/closure/testing/mock.js:535:24
> goog.testing.StrictMock.$verify at http://localhost:8000/javascript/closure/testing/strictmock.js:119:12
> anonymous at http://localhost:8000/javascript/closure/testing/mockcontrol.js:91:7
> Array.forEach
> Object.goog.array.forEach at http://localhost:8000/javascript/closure/array/array.js:203:43
> goog.testing.MockControl.$verifyAll at http://localhost:8000/javascript/closure/testing/mockcontrol.js:90:14
> anonymous at http://localhost:8000/javascript/crypto/e2e/extension/ui/glass/composeglass_test.js:235:17
> anonymous at http://localhost:8000/javascript/crypto/e2e/extension/testingstubs.js:32:5
> testRenderWithMissingRecipient at http://localhost:8000/javascript/crypto/e2e/extension/ui/glass/composeglass_test.js:226:10
> goog.testing.TestCase.Test.execute at http://localhost:8000/javascript/closure/testing/testcase.js:1293:12
> goog.testing.AsyncTestCase.doExecute_ at http://localhost:8000/javascript/closure/testing/asynctestcase.js:878:19
> goog.testing.AsyncTestCase.callTopOfStackFunc_ at http://localhost:8000/javascript/closure/testing/asynctestcase.js:756:10
> goog.testing.AsyncTestCase.pump_ at http://localhost:8000/javascript/closure/testing/asynctestcase.js:805:16

They seem to always pass when run individually though.

There's no pure-JS OpenPGP (or crypto) library of similar quality.

The crypto really merits its own project, especially as many Node.js people are using rather poorly written alternatives.

See google/end-to-end#244 for the parallel issue.

I have a branch somewhere that adds support for attachments in Yahoo mail via PGP/MIME formatting. I think this is open as a pull request in google/end-to-end, but I should rebase and open this here too.

Currently due to the "tabs" permission, user gets a warning saying the extension has access to browsing history. Does chrome allow more granular permissions so the extension can open a new tab, but not have access to browsing history?

The Travis-CI build fails on the after_script linting. Because there are so many lint errors that Travis eventually times out.

Possible Travis bug: Should timing out in an after_script action fail a build?

pnelson: yzhu: fixed width anything is awesome. Menlo Regular is nice for mac users.
pnelson: 11pt Menlo Regular
pnelson: or 10 pt

In the looking glass, text outside of the PGP armor is ignored. So if I forward an email that has been clear-signed, users can't see the part outside of the forwarded mail.

this is found with a MBA 13"

This is what I see in compose glass:

This is what chrisrohlf sees:

I think this will be done with #6 but is perhaps high enough priority that it should be done sooner, depending on how long/complicated the rebase is.

from @andres-erbsen referring to https://github.com/yahoo/end-to-end/pull/58/files#diff-a0c7c92381b7dc233e58a7f3139fe63cR36

We actually want better tests for this; even just code coverage is better than nothing here. My code does not seem to have any either, sorry about that. I do not have time to implement this right now and I am not sure when I will. So I am just writing something here with no well-thought intent. Some things that are probably true, and if they are, would be useful to check:

• Any multiple of the base point should unmarshal correctly.
• The blacklisted points at http://cr.yp.to/ecdh.html#validate should return error (but the list there is in X25519 format, not ed25519)
• The identity point should return error.
• The points of order 2 and of order 4 from https://christianepeters.files.wordpress.com/2012/10/20080710-s3cm.pdf should return error.
• x_B + y_S should return error if B is the base point and S is a point of order 2 or order 4 and y is less than its order.

There is an additional complication that a normal elliptic curve library might not even care to support the "bad" points, so using them for testing might end up being awkward. In particular, multiplication y*S does clear the low bits of y in some libraries, which would not work here.

The XSS potential with running as an extension makes a lot of people rightfully nervous. There is an upstream Google branch that moves to an app instead. We should do that too.

If we want to allow changing the profile signing key, we must make sure we store secret keys for both the old and the new profile signing key, and that for signing updates we use the one that the keyserver considers active. This is critical for not getting stuck in case the client misses a success reply to an update that actually went through.

Hi ，when I Register the Yahoo developer account，and Create my APP，I had No permission to access Yahoo mail API，the mail API is canceled ？how I Can access Yahoomail API，or any good ideas？thanks ~

from @dougdeperry:

Bug Description:

E2E injects an iframe into the compose or read message body in order to display signed or encrypted contents. E2E determines when to inject this iframe based on the presence of standard PGP message blocks. For example:

-----BEGIN PGP MESSAGE-----
Charset: UTF-8
Version: Yahoo Mail E2E v0.3.1341

-----END PGP MESSAGE-----
Whenever E2E sees a message block that looks like this it will inject the E2E iframe regardless of whether the message is properly signed or encrypted. If an attacker spoofs the from email address and uses the ‘BEGIN PGP MESSAGE’ in the message body E2E will inject the iframe even if the message contains no legitimately signed or encrypted content. This can give the impression that the message is legitimate which can aide in phishing attacks.

Reproduction Steps:
Send an email with the following text:

-----BEGIN PGP MESSAGE-----
Charset: UTF-8
Version: Yahoo Mail E2E v0.3.1341
This is a legitimate message from Yahoo. Please goto http://www.downloadmymalware.com
-----END PGP MESSAGE-----
See appendix A for a screenshot of the received message.

Mitigation:

If an error is detected during decryption/display, remove the injected iframe and just display the plaintext message contents and/or create a smaller iframe (or one that somehow looks different than the correct one) and display an error message.

dougdeperry:

The UI should not let allow you to “Lock keyring” if you do not have a passphrase already set. Maybe
attempting this action should take you to the "create a passphrase" workflow?

dgil:

Actually, this could be reasonably sensible, given how things work right now. It's possible to create a
non-extractable wrapping key, and then encrypt before serializing to localStorage via a shim.

(This may or may not be useful in the least, but for exactly the same reasons passwords may not be
very useful.)

When the key server is not available and one got an email which is signed with a key that the extension has never seen, it would report "BAD signature". It makes me feel like there is an active attack going on. However, it is not.

So, would it be making more sense to report "key server not available" in this case?

Here is the screenshot of the error:

The read/compose glasses are implemented as chrome-extension:// iframes running in *.mail.yahoo.com. Therefore, if users have disabled 3rd party data in Chrome prefs, the iframe can't use window.localStorage.

Related: #3

Clicking the "make key" button in the options page prompts you to delete the existing key for the email address in order to generate the key. This probably won't be done very often, so it should go behind the advanced preferences jump.

Responses from the keyserver are sometimes unintentionally put into the page's localStorage instead of Chrome extension localStorage. This isn't a security issue since the localStorage'd responses aren't used for anything right now and don't contain any sensitive information that the page doesn't already know, but it should still be fixed.

(Originally we were going to use a local index of keyserver responses to prune the keyring for keys that weren't sufficiently fresh and should therefore be untrusted.)

@expose is deprecated and should be replaced by @nocollapse or @export.

Here's a discussion about the motivation for deprecating @expose.

download-libs.sh installs the compiler from https://github.com/google/closure-compiler, which marks @expose as deprecated. Until this is fixed you can avoid the build errors by downloading an older release of the compiler from here. The most recent release works fine.

Repro steps:

1. ./do.sh testserver
2. go to http://localhost:8000/src/javascript/crypto/e2e/extension/ui/panels/keyringmgmt/keyringmgmtmini_test.html?runTests=testImportKeyring in Chrome (I run Version 41.0.2272.89 (64-bit)).

I get the following error:

localhost:8000/src/javascript/crypto/e2e/extension/ui/panels/keyringmgmt/keyringmgmtmini_test.html?runTests=testImportKeyring
1 of 12 tests run in 521ms.
0 passed, 1 failed, 11 suppressed by querystring.
521 ms/test. 297 files loaded.
.
09:35:35.702  Start
09:35:35.717  testImportKeyring [testImportKeyring] : FAILED (run individually)
09:35:35.720  ERROR in testImportKeyring [testImportKeyring]
Cannot read property 'closure_lm_420544' of null
> (unknown)
> Object.goog.events.getListenerMap_ at http://localhost:8000/javascript/closure/events/events.js:932:24
> Object.goog.events.listen_ at http://localhost:8000/javascript/closure/events/events.js:229:33
> Object.goog.events.listen at http://localhost:8000/javascript/closure/events/events.js:183:24
> goog.events.EventHandler.listen_ at http://localhost:8000/javascript/closure/events/eventhandler.js:175:35
> goog.events.EventHandler.listen at http://localhost:8000/javascript/closure/events/eventhandler.js:121:15
> panels.KeyringMgmtMini.enterDocument at http://localhost:8000/javascript/crypto/e2e/extension/ui/panels/keyringmgmt/keyringmgmtmini.js:271:7
> goog.ui.Component.render_ at http://localhost:8000/javascript/closure/ui/component.js:713:10
> goog.ui.Component.render at http://localhost:8000/javascript/closure/ui/component.js:655:8
> testImportKeyring at http://localhost:8000/javascript/crypto/e2e/extension/ui/panels/keyringmgmt/keyringmgmtmini_test.js:150:9
> goog.testing.TestCase.Test.execute at http://localhost:8000/javascript/closure/testing/testcase.js:1293:12
> goog.testing.AsyncTestCase.doExecute_ at http://localhost:8000/javascript/closure/testing/asynctestcase.js:878:19
> goog.testing.AsyncTestCase.callTopOfStackFunc_ at http://localhost:8000/javascript/closure/testing/asynctestcase.js:756:10
> goog.testing.AsyncTestCase.pump_ at http://localhost:8000/javascript/closure/testing/asynctestcase.js:805:16
> goog.testing.AsyncTestCase.runTests at http://localhost:8000/javascript/closure/testing/asynctestcase.js:508:8
> goog.testing.TestRunner.execute at http://localhost:8000/javascript/closure/testing/testrunner.js:270:19
09:35:36.223  Done

A bunch of the prompt panels in the codebase are not used. Removing them makes the tests run faster.

Hey there,

I tested googles-end-to-end and today I wanted to test yours, but when I try to build extension (./do.sh build_extension) there is a bug. There is always a message, saiing, "Download libraries needed to build first. Use ./do.sh install_deps". I did it!.

But when I do ./do.sh install_deps there is always an error:
"./download-libs.sh: 30: ./download-libs.sh: svn: not found"

Is there somebody who can fix it please? Or can tell me, how I can solve the problem?

Thanks a lot.

@struct: Do we have boilerplate?

Seems to have been caused by #8

If we want to avoid the need for manual recovery in case a profile update makes it to the keyserver but the reply does not make it back, the client should retry the update until it gets a definitive response. Not doing this can cause the affected client to sign messages using the previous PGP key while its contacts see the results of an update whose reply got list (and thus they reject the signatures).

Awesome. Another standard for fetching keys. Keybase did it, so why not you? (Keybase actually is a slight bit easier to fetch from, and I'll get to it in a second)

There's a HUGE number of people who already have their pubkeys on keyservers such as MIT's cryptonomicon.mit.edu (commonly known as pgp.mit.edu). For instance, my personal key, 46652712679A49D0402DE45145118824A8B6F243 is available there.

HKP is defined in an RFC which is pretty old.

It's also damn simple. There's two modes; Human (HTML) and Machine (text). To find my key using HKP, make a request like this:

http://pgp.mit.edu:11371/pks/lookup?search=46652712679A49D0402DE45145118824A8B6F243&op=index&options=mr

you get this:

info:1:1
pub:46652712679A49D0402DE45145118824A8B6F243:1:4096:1280896106::
uid:Morgan Gangwere <[email protected]>:1426360039::
uid:Morgan Gangwere <[email protected]>:1330284891::
uid:Morgan Gangwere <[email protected]>:1426360039::
uid:Morgan Gangwere (xmpp alias) <[email protected]>:1426359975::
uid:Morgan Gangwere <[email protected]>:1425539877::
uid:Morgan Gangwere (outlook alt) <[email protected]>:1423102493::
uat::::
uat::::

To actually fetch the PGP key, change op to fetch:

http://pgp.mit.edu:11371/pks/lookup?search=46652712679A49D0402DE45145118824A8B6F243&op=fetch&options=mr

You get

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: SKS 1.1.5
Comment: Hostname: pgp.mit.edu

mQINBExY7GoBEACX3J4A37mHFDGDxJXG979mpVirCo+FD527zfDbMvr964173jmh6xKEEiVZ
BJc2lChosjH5UV6UXD3hrO6JrM0kN0pYcjdLsex0GlTercoz9HEPlh+zuC1hk1Mmq2kXcpYx
HiXHLRsUO9KzYnZL9+AozetuP7y6pRe4o0BPuHngoZ8dETqPDjeLI8Pcf0EYxsck7LMrrCEk
3HHBt7ExmcnP+/N0he9qZl8Ky8FXb3S/Kcffq+WnnQzj+goPeqi92TniLu3e/V8PvEPGIe0F
....

Port 80 is also used because firewalls.

Keybase.io has a straightforward API for this. You ask them for a key ID. They spit back an infoblob about that person, including a PGP bundle and some info about the person.

(tiny point: This is a blocker for me using it, or at this point, anyone using it who doesn't have some serious infrastructure)

When using e2e, I can't select any of the content in the emails. This is inconvenient, as I can't copy (for example) links or other text from an email.