[tor-dev] [GSoC] HTTPS Everywhere secure ruleset update mechanism update

[Red]

Hello everyone,
I would like to quickly summarize what has been going on for the last
couple of weeks of my work.  Due to my mentor, Yan, being away on
travel, we haven't had time to have a formal weekly meeting on IRC as
per usual.  We have, however, been emailing on the HTTPS Everywhere
mailing list frequently to discuss some of the problems I've been
working on last week.  We have also compiled a list of things I am to
work on for the next week, which I will summarize here.

For the past week, I have been grappling with a problem pertaining to
digital signature verification using the nsIDataSignatureVerifier XPCOM
component designed to handle this task.  I had written a few tests[1]
that would use the testing mechanism that Yan built to make sure that
the hashing and signature verification my project would rely on for
security was working.  The testing mechanism was built after our last
meeting the Friday before last, during which time we realized we could
write a separate Firefox extension using the addon SDK (and thus,
Jetpack's testing suite) and import the HTTPS Everywhere component into
that extension for testing purposes.

Despite the fact that the process for producing the signature in
question[2] seemed to work fine- Openssl was able to generate and verify
the signature, the testing code calling the verifyData[3] function used
for verification was returning an undocumented NS_ERROR_FAILURE
exception.  I had spent a great deal of time asking for support in
relevant Firefox extension development IRC channels, reading source code
from unit tests for the nsIDataSignatureVerifier component, and
experimenting with alternative openssl commands in order to try to
figure out why this error was occurring. 

Yan was able to get the test to pass by generating a key and signature
using the NSS tools.  However, she has said that this process is more
involved than we would like, and is not likely feasible to accomplish on
EFF's airgapped machine hosting its offline private signing key due to
the lack of availability of NSS tools.  To overcome this limitation, I
will be porting one of either the Uhura tool that has been used in the
past, or the pk1sign program[4] Yan had found referenced in a Bugzilla
report.

For now, that's what I'll be doing.  I am feeling optimistic that, once
this issue of generating an appropriate (i.e. verifiable by
nsIDataSignatureVerifier) signature is resolved, writing tests for and
refactoring the secure update mechanism I am building will be complete
before long.

I have compiled some of the discussion Yan and I have had via email into
my weekly meeting notes[5], despite there having not been an actual
meeting.  As usual, I welcome any advice and input!

Cheers,
Zack

[1]:
https://github.com/redwire/https-everywhere/blob/feature/tests/https-everywhere-tests/test/test-rsupdate-verify.js
[2]:
https://github.com/redwire/https-everywhere/blob/rulesetUpdating/doc/updateJSONSpec.md#updatejson-and-updatejsonsig
[3]:
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIDataSignatureVerifier
[4]:
http://dxr.mozilla.org/mozilla-central/source/security/nss/cmd/pk1sign/pk1sign.c
[5]: https://gist.github.com/redwire/b62f03905a826e79947a#week-8

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 341 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140707/46f796fc/attachment.sig>