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-everywh... [2]: https://github.com/redwire/https-everywhere/blob/rulesetUpdating/doc/updateJ... [3]: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interf... [4]: http://dxr.mozilla.org/mozilla-central/source/security/nss/cmd/pk1sign/pk1si... [5]: https://gist.github.com/redwire/b62f03905a826e79947a#week-8
On 2014-07-07 20:40, Red wrote: [.. lots of cool work being worked on ..]
Hi Zack,
Seems you are doing lots of cool stuff ;)
But I am one of those strange people who really hate it that every separate tool has their own updater (which can be used for tracking a user, as the set of updater tools polling servers makes a fingerprint in the same way other flows make a fingerprint).
And thus I run Little Snitch and block those updates. Till I deem it a good time for the update to be done and trigger it manually.
As such, when you get to the stage of adding features, it would be good if there was: - an option to disable the auto fetching - an option to trigger the fetching - to feed the update mechanism with a pre-fetched file (eg provided through a different update mechanism)
Greets, Jeroen
On 7 July 2014 19:40, Red redwire@riseup.net wrote:
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.
Looking at the pk1sign source, it looks like the signature needs to be in base64. Was that what you were using?
Do you have a test case that fails using command line tools?
-
Ben Laurie -
Jeroen Massar -
Red