Our session on Friday about Hidden Service Fingerprinting wandered a
lot. Ultimately, we concluded that it will be hard to fully defend
against this attack without a more formally specified state machine that
describes hidden service circuit usage fully.
However, we may still be able to extend the Netflow Padding defense to
pad more often during circuit setup, which should at least improve the
situation against an adversary that is externally monitoring the Guard
node.
Here's the specific action items from the session yesterday:
* Review Prop 224 and other proposals for distinguishes for client traffic
* Specify a protocol state machine as part of the design
* If it is more complicated than the TCP state machine, we should
run in fear
* Otherwise, researchers should be able to make use of this state
machine to determine optimal padding
* Netflow padding should have a state to cover circuit setup
* Based on Circuit Build Timeout
* This allows only 2-10 seconds or so of more frequent padding
* The "HS's sometimes need to use a second Guard" distinguisher
* The RP should never be a Guard node
* The third level node should never be a Guard node
* TBB Update pings over HS
* Increases the Base Rate, since more clients are building hidden
service circuits
* This is far easier to do for the Torbutton RecommendedTBBVersions
fetch since the updater has special cert pinning that would need to
be altered for hidden services
* Future Research:
* Conflux + Guard Sets
* Provides Redundancy against active delay and DoS attacks
* May help against fingerprinting and correlation
* However, still won't help against a datacenter adversary :/
--
Mike Perry
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev