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

[Jeroen Massar <jeroen@xxxxxxxxx>]

On 2014-07-08 12:47, Yan Zhu wrote:
> (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 300000. I'm curious if others have
>> more refined suggestions!

When the update happens over Tor you are mostly fine. But then you have
to make sure that the update happens over Tor. That is fine for Tails,
but not guaranteed for TBB.

Hence, my concern is for leaked connections outside of Tor. Eg, when
connecting to a wireless network at Starbucks. The moment one has a
forced VPN/Tor setup that one trusts, it is less of an issue.

If somebody can fingerprint timing info in Tor, then well, we have
bigger problems there ;)

(and indeed, having the updates come in through either Apple App Store,
Debian's APT repos etc, is an advantage as that only tells an adversary
"hey another OSX/Debian user" and not much else; oh and yes, app store
updating is disabled too on my hosts ;)


>>> 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. :)

Indeed. Thus it would be good if the system allows that.

>> 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.

Yes, that might not be the best method. Especiallly when you get it from
a 'stable' source (eg TBB) that one does not update every once in a while.

Note that I see HTTPS Everywhere being used for other purposes than just
the standard checks it performs today, and then the updates might have
to be a lot more frequent than the software update happens.

Greets,
 Jeroen


_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev