[HTTPS-Everywhere] Verifying signatures in a FF extension?

Yan Zhu yan at eff.org
Fri Jul 4 02:02:31 PDT 2014


At a glance, it seems like your signature string is not properly
encoded. The first bytes should be "MII" for a Base64 encoding of a
DER-encoded signature.

Unfortunately I don't think I can make the usual IRC meeting tonight
because I'm in France - let's try to meet on Monday instead?

-Yan

On 07/03/2014 07:36 AM, Red wrote:
> Here's all of the test output on pastebin: http://pastebin.com/mYyw3WNW
> The exact exception message I am getting is:
> 
> Message: [Exception... "Component returned failure code: 0x80004005
> (NS_ERROR_FAILURE) [nsIDataSignatureVerifier.verifyData]"  nsresult:
> "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame ::
> resource://gre/modules/addons/XPIProvider.jsm ->
> jar:file:///Users/redwire/Developer/Sources/Projects/https-everywhere/test_profile/extensions/jid1-we5BQOfc6skSMg@jetpack.xpi!/bootstrap.js
> -> resource://gre/modules/commonjs/toolkit/loader.js ->
> resource://jid1-we5bqofc6sksmg-at-jetpack/https-everywhere-tests/tests/test-rsupdate-verify.js
> :: exports["test update JSON signature validity"] :: line 78"  data: no]
> 
> On 2014-07-02, 10:05 PM, Yan Zhu wrote:
>> On 07/02/2014 10:00 PM, Red wrote:
>>> Hello everyone,
>>>     I've been working on writing some tests[1] for signature
>>> verification and hashing using the unit testing solution Yan built after
>>> we discussed some new ideas during our meeting last week, but have had
>>> no success in getting signature verification working.  I've been using
>>> the nsIDataSignatureVerifier XPCOM component[2] to do this, using some
>>> testing data and an RSA key pair[3] I generated just for testing. All of
>>> my tests with hashing have worked perfectly well and are passing, but
>>> for some reason my attempt at verifying the signature I created are
>>> leading to an exception being thrown.  I followed the process I outlined
>>> in the update.json spec to create my key pair, an example update.json
>>> file, and to sign the hash of the contents of update.json[4].
>> Could you post the exception that you're getting and the test output?
>>
>> -Yan
>>
>>>     I've asked on both the #extdev and #jetpack channels of
>>> irc.mozilla.org about this, and have scoured Google, Duck Duck Go, MDN,
>>> and Stack Overflow for an answer to the question of what could cause
>>> this behavior (and have referenced some code I found on github to
>>> confirm I had hardcoded my public key and signature correctly), and
>>> haven't turned up anything that brings me anywhere near a solution.  So,
>>> I come to you.   As people who have worked on HTTPS Everywhere, are any
>>> of you familiar with the process for verifying signatures, and could you
>>> perhaps review my test to see if I've done something wrong?  Are there
>>> any alternative ways of verifying signatures (perhaps using an external
>>> library) that might be more reliable?
>>>
>>> Thanks,
>>> Zack
>>>
>>> Note1: my `ruleset_update_manifest.py` script doesn't append a newline
>>> character to the end of the written `update.json` file, but I had added
>>> one accidentally while playing with the content in vim. Rather than
>>> hashing and signing the file again, I decided to simply append a newline
>>> character to the hardcoded data in my test code.
>>>
>>> Note2: I've gone through a lot of permutations of, what I hope are,
>>> reasonable modifications to my test code to try to resolve this issue,
>>> so I highly recommend having a peek through the commit history on [1] to
>>> get an idea of what I've been trying.
>>>
>>> [1]:
>>> https://github.com/redwire/https-everywhere/blob/feature/tests/https-everywhere-tests/test/test-rsupdate-verify.js
>>> [2]:
>>> https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIDataSignatureVerifier
>>> [3]:
>>> https://github.com/redwire/https-everywhere/tree/rulesetUpdating/utils/testing/sign_verify
>>> [4]:
>>> https://github.com/redwire/https-everywhere/blob/rulesetUpdating/doc/updateJSONSpec.md#updatejson-and-updatejsonsig
>>>
>>>
>>>
>>> _______________________________________________
>>> HTTPS-Everywhere mailing list
>>> HTTPS-Everywhere at lists.eff.org
>>> https://lists.eff.org/mailman/listinfo/https-everywhere
>>>
>>
> 
> 
> 
> 
> _______________________________________________
> HTTPS-Everywhere mailing list
> HTTPS-Everywhere at lists.eff.org
> https://lists.eff.org/mailman/listinfo/https-everywhere
> 


-- 
Yan Zhu  <yan at eff.org>, <yan at torproject.org>
Staff Technologist
Electronic Frontier Foundation                  https://www.eff.org
815 Eddy Street, San Francisco, CA  94109       +1 415 436 9333 x134

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140704/e22b6396/attachment.sig>


More information about the HTTPS-Everywhere mailing list