Notes on TLS unobservability

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

Hi, all.  Roger needed a write-up on recent progress here, too, and
suggested it might be of general interest.

Remember, it *is not* a goal to make Tor steganographic.  For the
actual threat model, see proposal 124, and see also the blocking
resistance design document.


TLS NORMALIZATION
-----------------
The first round of TLS normalization is now done.  The most recent
changes involved poking at the internals of OpenSSL's ssl_st structure,
and moving ciphers around to get the right result.  Remember, we're
aiming to emulate Firefox's choice of ciphersuites... but Firefox lists
some suites that old OpenSSL versions (like 0.9.7) don't support at all,
and one suite that was never actually standardized, and therefore no
OpenSSL version has ever supported.


The code was pretty interesting to write.  For each SSL object, OpenSSL
keeps two lists of ciphersuites.  One list is sorted by preference (and
is used by clients to advertise which ciphers they support), and one is
sorted by ID and used to look up the suite when the server sends its
choice back to the client.  When Tor is as a client, it now changes the
first list before SSL negotiation so it can advertise the same suites as
Firefox does.  Tor servers never select these dummy ciphersuites.

As for extensions, Setting a desired hostname and picking some ECC
suites is enough to make recent OpenSSLs choose the extensions we want.

HOW TO TEST THIS
----------------
I've looked at the packet dump, and it looks okay to me.  But from a
red-team POV, I'm going to ask Steven and Jacob to act as a red team and
see what they can do to reliably distinguish Tor-to-Tor traffic from
Firefox-to-webserver traffic without resources beyond what a typical
firewall can do.  Looking at traffic patterns should work, but I don't
think you can do this without expending more RAM per connection than
big firewalls can afford.

SSL PASSTHROUGH
---------------
For rudimentary scanning resistance, it might be interesting to support
some kind of authentication, so that clients who come to a bridge
without authenticating are passed on to a local service (like a
webserver) so that the host seems to be an ordinary encrypted webserver.

Implementing this in Tor would not be difficult, but it would be One
More Darned Feature To Do and would take time from other stuff, so we
need to consider it judiciously.  Implementation/Design issues include:
  - We'd need support for having the server's SSL certificate seem like
    a plausible certificate for the website, or for using an external
    key/certificate for SSL connections.  Both seem a bit problematic.
  - We'll need to refactor the code; right now, "this connection speaks
    Tor cells" is synonymous with "this connection is using SSL."
  - Having Tor pass connections off to another server as needed is only
    one option.  Alternatively, we could have an external program
    multiplex a appropriate.

Fundamental issues include:
  - Would it really work?  A clever probing adversary might be able to
    pull off some kind of timing attack.  To answer this, we should get
    intuitions from the academics we know who work on fingerprinting.
  - What's the threat model?  An adversary with the resources to probe a
    large number of IP/port combinations for possible Tor bridges, most
    likely.  Are the resources needed to do this really less than the
    resources needed to mount a really effective attack against the
    bridge distributor?