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.