[tor-dev] "Seeing through Network-Protocol Obfuscation"

[Yawning Angel]

On Fri, 21 Aug 2015 17:46:39 -0700
Kevin P Dyer <kpdyer at gmail.com> wrote:

> > The authors suggest active probing to reduce false
> 
> > positives, but don't mention that this doesn't work against obfs4
> > and
> 
> > meek.
> 
> I don't want to get too off track here, but do obfs4 and meek really
> resist against active probing from motivated countries? Don't we
> still have the unsolved bridge/key distribution problem?

meek does because the entry point into the Tor network is a well known
high traffic CDN platform.  So an adversary can see that there is a
meek instance running on a given CDN (since it's not a secret), along
with content that people want to see, so distinguishing between normal
traffic/meek traffic requires a TLS break or statistical attacks.

I personally hold distribution to be orthogonal to circumvention
protocol design in the context of obfs4 (scramblesuit, fte, and other
bridge based circumvention protocols), because if someone breaks the
bridge distribution mechanism, the protocol is irrelevant since the
attackers win by virtue of having the IP address/Port of the
obfuscated server[0].

Assuming all the adversary sees is the obfs4/scramblesuit stream, then
both are active probing resistant, because it requires compromising a
separate system to be able to generate a valid handshake for probing.

Active probing attacks should be able to defeat a scenario like:

  "I setup a unlisted bridge, firewall off the ORPort and GPG
   e-mail/OTR/Pond a series of bridge lines to a collaborator in
   China."

  The adversary gets to see the IP address/Port of the obfuscated
  server, and can send traffic as they see fit.

Note: There's a few other things an adversary can do under the
assumption that whatever is speaking obfs4 is probably a Tor
client/bridge pair. But those are attacks against either the Tor
network, or limitations of the tor implementation itself[1].

Regards,

-- 
Yawning Angel

[0]: Distribution still is an important problem that needs to be
solved, and maybe linking it closer to the protocol design is something
that is required.  Open research questions are open.
[1]: Likewise this stuff is important and should be/will be fixed, but
they are Tor issues and not "obfs4/fte/whatever" issues.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150822/c004e9d4/attachment-0001.sig>