tor/changes/prop171

  o Major features:
    - You can now configure Tor so that streams from different
      applications are isolated on different circuits, to prevent an
      attacker who sees your streams leaving an exit node from linking
      your sessions to one another.  To do this, choose some way to
      distinguish the applications -- have them connect to different
      SocksPorts, or have one of them use SOCKS4 while the other uses
      SOCKS5, or have them pass different authentication strings to
      the SOCKS proxy.  Then use the new SocksPort syntax to configure
      the degree of isolation you need. This implements Proposal 171.

  o Minor features:
    - There's a new syntax for specifying multiple client ports (such as
      SOCKSPort, TransPort, DNSPort, NATDPort): you can now just declare
      multiple ...Port entries with full addr:port syntax on each.
      The old ...ListenAddress format is still supported, but you can't
      mix it with the new SOCKSPort syntax.

  o Code simplifications and refactoring:
    - Rewrote the listener-selection logic so that parsing which ports
      we want to listen on is now separate form binding to the ports
      we want.
Implement stream isolation This is the meat of proposal 171: we change circuit_is_acceptable() to require that the connection is compatible with every connection that has been linked to the circuit; we update circuit_is_better to prefer attaching streams to circuits in the way that decreases the circuits' usefulness the least; and we update link_apconn_to_circ() to do the appropriate bookkeeping. 2011-07-06 23:08:24 +02:00			`o Major features:`
			`- You can now configure Tor so that streams from different`
			`applications are isolated on different circuits, to prevent an`
			`attacker who sees your streams leaving an exit node from linking`
			`your sessions to one another. To do this, choose some way to`
			`distinguish the applications -- have them connect to different`
			`SocksPorts, or have one of them use SOCKS4 while the other uses`
			`SOCKS5, or have them pass different authentication strings to`
			`the SOCKS proxy. Then use the new SocksPort syntax to configure`
			`the degree of isolation you need. This implements Proposal 171.`

Parse prop171 options; refactor listener/port option code Proposal 171 gives us a new syntax for parsing client port options. You can now have as many FooPort options as you want (for Foo in Socks, Trans, DNS, NATD), and they can have address:port arguments, and you can specify the level of isolation on those ports. Additionally, this patch refactors the client port parsing logic to use a new type, port_cfg_t. Previously, ports to be bound were half-parsed in config.c, and later re-parsed in connection.c when we're about to bind them. Now, parsing a port means converting it into a port_cfg_t, and binding it uses only a port_cfg_t, without needing to parse the user-provided strings at all. We should do a related refactoring on other port types. For control ports, that'll be easy enough. For ORPort and DirPort, we'll want to do this when we solve proposal 118 (letting servers bind to and advertise multiple ports). This implements tickets 3514 and 3515. 2011-06-30 20:01:02 +02:00			`o Minor features:`
			`- There's a new syntax for specifying multiple client ports (such as`
			`SOCKSPort, TransPort, DNSPort, NATDPort): you can now just declare`
			`multiple ...Port entries with full addr:port syntax on each.`
			`The old ...ListenAddress format is still supported, but you can't`
			`mix it with the new SOCKSPort syntax.`

			`o Code simplifications and refactoring:`
			`- Rewrote the listener-selection logic so that parsing which ports`
			`we want to listen on is now separate form binding to the ports`
			`we want.`