[Freedombox-discuss] making freedombox traffic indistinguishable [was: Re: Announcing Santiago Release Candidate 1]

[Daniel Kahn Gillmor]

On 05/22/2012 12:26 PM, Michael Rogers wrote:
> As I said before, this isn't necessarily a problem - it just raises
> the question of whether it's a design goal for the FreedomBox's
> traffic to be hard to distinguish from other traffic.

Complete indistinguishability for both client and server against an
active attacker who is willing to break some handshakes to identify at
least one of the parties involved is a seriously difficult (possibly
intractable) problem.  For one thing, the TLS handshake currently leaks
a lot of identifiable information about the server at least, as well as
the capabilities and extension offered by the client.

To make that sort of traffic indistinguishable from other traffic would
mean either:
 (a) negotiating the TLS handshake itself in some form of "bad faith",
       or
 (b) changing all the other TLS traffic such that the initial leakage
     doesn't happen.

I don't have any ideas how to legitimately do (a) without causing
serious technical breakage (including possibly violating some security
guarantees of TLS itself), and (b) is a lot of social (arm-twisting) and
technical (implementing) work.

If you're interested in following up more on (b), I recommend reading
the recent discussion about Marsh Ray's proposed encrypted-handshake on
the IETF's TLS Working Group discussion list, and following links from
there if you want to pursue this avenue further.

  https://datatracker.ietf.org/doc/draft-ray-tls-encrypted-handshake/
  http://thread.gmane.org/gmane.ietf.tls/9504

The short version: we can probably do better than the current TLS
negotiation at protecting the identities of the peers and details of the
handshake itself.  However, to defend against active attackers, these
protections are dependent on clients and servers being willing to "fail
closed" (currently uncommon) and will require some kind of non-trivial
changes to the way that TLS handshakes are handled (possibly even a new
version of TLS).

Even if we can reach a rough consensus on the way that interoperable TLS
peers can handle this sort of thing properly, the very act of choosing
something like an E-H mode could be used by middleware (censors,
surveillance proxies, etc) as a marker for illicit activity. Until these
changes are widespread in the rest of the ecosystem, it's going to be
very challenging to provide strong traffic indistinguishability from
"normal" traffic against a savvy and well-placed active attacker.

sorry to be the bearer of bad tidings,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20120522/6f430df9/attachment.pgp>