Re: [tor-dev] [HTTPS-Everywhere] [GSoC] HTTPS Everywhere secure ruleset update mechanism update
(resending to tor-dev with tp.o email address) On 07/08/2014 03:42 AM, Yan Zhu wrote: On 07/08/2014 12:07 AM, Jeroen Massar wrote: 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). Hi Jeroen, This makes a lot of sense. I'm aware of the fingerprintability concern, and EFF tech projects generally try to mitigate it by polling the update servers at randomized intervals over fresh Tor circuits if possible. For this project, we initially proposed polling for an update when the browser starts and every 3 hours plus some random, evenly-distributed number of milliseconds between 0 and 30. I'm curious if others have more refined suggestions! 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 Yes, this would be fairly easy to add. - an option to trigger the fetching Probably also easy. - to feed the update mechanism with a pre-fetched file (eg provided through a different update mechanism) Since the update mechanism is just an XHR that downloads a new ruleset library from a hardcoded static URL and replaces the existing one in the Firefox profile directory, you could fetch-and-replace this manually via any number of mechanisms. :) Also, the ruleset libraries will still ship with extension updates, so you could disable ruleset updates and just wait for the next HTTPS Everywhere release. -Yan Greets, Jeroen ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ___ HTTPS-Everywhere mailing list https-everywh...@lists.eff.org https://lists.eff.org/mailman/listinfo/https-everywhere -- Yan Zhu y...@eff.org, y...@torproject.org Staff Technologist Electronic Frontier Foundation https://www.eff.org 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x134 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [HTTPS-Everywhere] [GSoC] HTTPS Everywhere secure ruleset update mechanism update
(resending to tor-dev with tp.o email address) On 07/08/2014 03:30 AM, Yan Zhu wrote: On 07/08/2014 02:55 AM, Ben Laurie wrote: On 7 July 2014 19:40, Red redw...@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? I think Zack's original failing test case was generated via something like: $ openssl rsautl -sign -in update.digest -out signtmp.sig -inkey privkey.pem $ openssl base64 -in signtmp.sig -out update.json.sig as described in the original spec that we wrote: https://github.com/redwire/https-everywhere/blob/makeJSONManifest/doc/updateJSONSpec.md Here is the diff between the failing test and the passing test: https://github.com/redwire/https-everywhere/commit/8b3c85d9d90d679e8b69970173db9f3185fa44c3. I generated the data for the passing test with pk1sign. The documentation for nsIDataSignatureVerifier does not really describe the expected data format for the signature [1], so it took a while to figure out that it expects a very specialized form [2]. [1] https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIDataSignatureVerifier [2] https://bugzilla.mozilla.org/show_bug.cgi?id=685852#c0 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ___ HTTPS-Everywhere mailing list https-everywh...@lists.eff.org https://lists.eff.org/mailman/listinfo/https-everywhere -- Yan Zhu y...@eff.org, y...@torproject.org Staff Technologist Electronic Frontier Foundation https://www.eff.org 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x134 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Panopticlick summer project
(resending to tor-dev because the original message didn't go through) On 03/16/2014 11:52 PM, Yan Zhu wrote: On 03/16/2014 07:59 PM, Gunes Acar wrote: Dear All, My name is Gunes Acar, a 2nd year PhD student at Computer Security and Industrial Cryptography (COSIC) group of University of Leuven. I work with Prof. Claudia Diaz and study online tracking and browser fingerprinting. I'd like to work on Panopticlick (https://www.torproject.org/getinvolved/volunteer.html.en#panopticlick) summer project and other fingerprinting related issues which I tried to outline below: Hi Gunes, I think all of these projects below would primarily be with EFF, not Tor directly. Peter and/or I would be your point of contact; I'm not familiar enough with Panopticlick at this time to give you much feedback on the ideas below, so I cc'ed Peter. 1) Collaborate with Peter@EFF to port/open-source Panopticlick: https://trac.torproject.org/projects/tor/ticket/6119#comment:4 a) implement necessary modifications - e.g. we won't be having cookies or real IP addresses to match returning visitors. b) consider security implications of storing fingerprints (e.g. what happens if someone gets access to fingerprint database?) Peter, what's the blocker on this? It sounds like Tor folks really want it to happen soon, so I'm happy to take the lead on helping get this open-sourced from the EFF side. 2) Add machine-readability support outlined in Tor Automation proposals: https://people.torproject.org/~boklm/automation/tor-automation-proposals.html#helper-fingerprint a) which one(s) should we implement? JSON, YAML, XML? No input here. 3) Survey the literature for fingerprinting attacks published since Panopticlick. Implement those that may apply to TBB: a) Canvas WebGL fingerprinting (Mowery et al.) - make sure the patch at #6253 works b) JS engine fingerprinting (Mulazzani et al.) c) CSS rendering engine fingerprinting, (Unger et al.) This sounds greatly useful. Another good place to look is Mozilla's bug tracker (https://bugzilla.mozilla.org/). 4) Check with realworld fingerprinting scripts to see if they collect anything that is not considered before. Check if TBB's FP countermeasures work against them. (We can use data from FPDetective study to find sites with fingerprinting scripts) Same as above. 5) Backport new attacks found in 3 4 to EFF's Panopticlick in case they consider an update. Yes, I'm happy to get those updates into EFF's instance. 6) Convert fixed FP-related bugs into regression tests. https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprintingstatus=closed 7) Build test cases to check the severity of fingerprinting related open tickets, e.g.: https://trac.torproject.org/projects/tor/ticket/8770 https://trac.torproject.org/projects/tor/ticket/10299 8) Work on potential fingerprinting bugs that ESR31 may bring. 9) ESR transitions seem to create a lot of FP-related issues that need to be checked manually (e.g. #9608). Consider developing a tool that iterates over the host objects of two browsers to compare them automatically (e.g. to pinpoint new objects, new methods, updated default values, etc.). Similar to diff tool mentioned here: https://people.torproject.org/~boklm/automation/tor-automation-proposals.html#helper-fingerprint 10) Evaluate the font-limits of TBB by checking the average # of fonts Top 1 Million sites use. We can either collect fresh data with FPDetective or use the existing (~1 year old) data. All of the above sounds fine. Assuming that we can get Panopticlick open-sourced, I'm more than happy to help you with any of these subprojects. -Yan (EFF Staff Technologist / HTTPS Everywhere maintainer) ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
