Re: [Tails-dev] todo/network_fingerprint

Delete this message

Reply to this message
Author: intrigeri
Date:  
To: The Tails public development discussion list
Subject: Re: [Tails-dev] todo/network_fingerprint
Hi,

adrelanos wrote (06 Jul 2013 12:01:17 GMT) :
>> What's the answer to these questions, then?


> With the assumption that [1] is still accepted as it was earlier in this
> thread, it's as it follows.


>> Are such fingerprinting possibilities a serious problem?


> As per the new proposed fingerprinting design chapter, the answer is,
> for example, either:
> - "Yes."
> - "For (censorship circumvention mode/bridge users), yes."


> Now its a stylistic question whether you expect the design (which
> includes fingerprinting) to be read already or if you add some required
> knowledge block above or if you link to other connected design chapters.


OK.

> In response to...


>> What kind of efforts and compromise should be made to prevent these?


> Responding to...


>>> Tails runs HTP through Tor, so the fingerprintability should be
> limited to traffic flow only. It should be noted that HTP only fetches
> the HTTP header, so fingerprinting based on the known traffic pattern
> when fetching the full page of any of the members of Tails' HTP source
> pools is not possible.


> Since traffic flows over Tor, its the job of Tor (and the censorship
> circumvention tool) to prevent, that the ISP can guess what's inside
> that stream. If they fail at this, its a severe upstream bug. Hence, no
> network fingerprinting issue. The web fingerprint is not of concern,
> since (censorship circumvention mode/bridge users) are not affected as
> in successfully fingerprinted and access denied.


OK-ish: we can't simply wave known Tor issues away as someone else's
problem as if it did not affect us. Anyway, as long as we only fetch
the header, I doubt there's enough bits in there to set up any
relevant attack. I think this should be rephrased a bit as a patch
against contribute/design/Time_syncing.mdwn.

> Responding to...


>>> Our initial time guess based on the Tor consensus is probably easier
> to fingerprint, though: a fresh Tor is started, and restarted again
> right after the consensus has been downloaded.


> When the fingerprinting design is accepted as proposed, the answer is:
> not a design goal, since no (censorship circumvention mode/bridge users)
> are affected. Probable also, patches still welcome.


OK. Same here: please rephrase this as a patch against
contribute/design/Time_syncing.mdwn :)

Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc