[tor-dev] What Should Tor Bridges and Clients Do When They Get Hosed?

[George Kadianakis]

This is not a proposal.

So, since some people in this list, who are not in IRC, seemed
interested in censorship resistance, I pose this new question: What
should Tor bridges and clients do when they hosed in previous schemes?

All those previous proposals dealed with ways to detect fingerprinting
adversaries, but not with ways to persuade them that what they are
seeing is not Tor. There should be a proposal specifying exactly that,
and this is a discussion thread (even monologue can be considered a
discussion).

Let's start with a quick threat model:

---
We consider a nation-state adversary who:
a) has a list of hosts suspected to be Tor bridges and wants to
   block them without suffering huge false positives.
OR
b) sails the Internet to find Tor bridges.

The adversary is controlling the state's Internet infrastructure
and can inject, modify or block incoming or outgoing traffic.

He can build software that speaks and understands network protocols
but he cannot deploy humans to do the necessary testing.

To complete his goals, the adversary can directly probe hosts to
see what protocol they speak, OR he can MITM all connections
towards those hosts to see what protocol their clients speak.
---

tl;dr we are dealing with MITMs and direct probes here.

Naturally, it would be cool if we could just say "Oh right, all
bridges and clients speak HTTPS in case of detection; all is cool",
but remember that HTTPS is quite hard to spoof right, both in the
server and in the client case [1], especially when it has to be done
in C and in the tor.git codebase.

Ideally, we would want to be as application-layer-neutral [2] as
possible, and with the minimum implementation cost possible.

So let's handle client and bridge cases separately and have a go.

Clients:

Proposal 191 allows clients to detect MITM attempts during the SSL
handshake, this is good because we don't have to pretend speaking a
specific application layer protocol.

I think a good solution would be to send an SSL Alert of "Bad
Certificate" type and close the connection when clients detect an SSL
MITM attempt.

That's what Firefox does when a user selects "Get Me Out Of Here!" on
the self-signed certificate dialog, and that's what all applications
should do (?) when an MITM attack is detected either by certificate or
public-key pinning.

In the future we might also want to send innocuous HTTP queries like
GETting index.html, but we have to be aware of [1].

Bridges:

Bridges have it harder.

Proposal 187, allows bridges to detect probing attempts after the SSL
handshake, when the probing client sends any sort of packet or a badly
formed AUTHORIZE cell.

This forces bridges to respond with an application-layer-specific
message (or close the connection, but that would be rude).

This is where I'm not sure what should be done.

I think all implementations MUST provide a way for the bridge operator
to configure a network service of his own (FTPS, HTTPS, SMTPS, etc.)
and have the bridge send all the adversary traffic to that service.

That should do it for technical bridge operators, but there probably
should also be something on by default, for bridge operators who don't
know how to setup net services on their own.

The easy choice is an "HTTPS" server with the default Apache "It
Works!", or a closed basic access authentication, but really
implementing a spoofed HTTPS server in tor will be a PITA, because
censors can easily test us by provoking one of [0] (there is a reason
that HTTP servers usually require lots of LoCs to work).

Maybe we should ship a configured Apache server with the long-term
future "Anti-censorship Tor Bundle"?

Also, what happens to Tor on Linux when it can't listen on port 443?
Or when port 443 is already taken? HTTPS servers on 9001 sure look
sketchy.

Any ideas are welcome.

Any services widely used, frequently seen with SSL support, that
handle traffic that kinda looks like Tor's and are easily
implementable, are also welcome.


[0]: https://en.wikipedia.org/wiki/List_of_HTTP_status_codes
[1]: https://en.wikipedia.org/wiki/List_of_HTTP_header_fields
     https://trac.torproject.org/projects/tor/ticket/2907
[2]: Let's place SSL on the transport layer for now.