TODO 11 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264
  1. Legend:
  2. SPEC!! - Not specified
  3. SPEC - Spec not finalized
  4. NICK - nick claims
  5. ARMA - arma claims
  6. - Not done
  7. * Top priority
  8. . Partially done
  9. o Done
  10. D Deferred
  11. X Abandoned
  12. For scalability:
  13. - Slightly smarter bandwidth management: use link capacity
  14. intelligently.
  15. - Handle full buffers without totally borking
  16. For dtor:
  17. NICK pre1:
  18. o make all ORs serve the directory too.
  19. o "AuthoritativeDir 1" for dirservers
  20. o non-authorative servers with dirport publish opt dircacheport
  21. o make clients read that and use it.
  22. o make clients able to read a normal dirport from non-trusted OR too
  23. o make ORs parse-and-keep-and-serve the directory they pull down
  24. o authoritativedirservers should pull down directories from
  25. other authdirservers, to merge descriptors.
  26. D Have clients and dirservers preserve reputation info over
  27. reboots.
  28. [Deferred until we know what reputation info we actually want to
  29. maintain. Our current algorithm Couldn't Possibly Work.]
  30. . allow dirservers to serve running-router list separately.
  31. o "get /running-routers" will fetch just this.
  32. o actually make the clients use this sometimes.
  33. o distinguish directory-is-dirty from runninglist-is-dirty
  34. - ORs keep this too, and serve it
  35. - Design: do we need running and non-running lists?
  36. o tor remembers descriptor-lists across reboots.
  37. . Packages define datadir as /var/lib/tor/. If no datadir is defined,
  38. then choose, make, and secure ~/.tor as datadir.
  39. o Adjust tor
  40. o Change torrc.sample
  41. D Change packages (not till 0.0.8 packages!)
  42. - Look in ~/.torrc if no */etc/torrc is found?
  43. o Contact info, pgp fingerprint, comments in router desc.
  44. o Add a ContactInfo line to torrc, which gets published in
  45. descriptor (as opt)
  46. o write tor version at the top of each log file
  47. pre2:
  48. - refer to things by key:
  49. o extend cells need ip:port:identitykeyhash.
  50. . Lookup routers and connections by key digest; accept hex
  51. key digest in place of nicknames.
  52. . Audit all uses of lookup-by-hostname and lookup-by-addr-port
  53. to search by digest when appropriate.
  54. - Rep-hist functions
  55. - also use this in intro points and rendezvous points, and
  56. hidserv descs. [XXXX This isn't enough.]
  57. - figure out what to do about ip:port:differentkey
  58. ARMA - ORs connect on demand. attach circuits to new connections, keep
  59. create cells around somewhere, send destroy if fail.
  60. - nickname defaults to first piece of hostname
  61. - running-routers list refers to nickname if verified, else
  62. hash-base64'ed.
  63. - put OR uptime in descriptor
  64. - name the secret-key directory something to discourage people
  65. from mailing their identity key to tor-ops
  66. pre3:
  67. - users can set their bandwidth, or we auto-detect it:
  68. - advertised bandwidth defaults to 10KB
  69. - advertised bandwidth is the min of max seen in each direction
  70. in the past N seconds.
  71. - not counting "local" connections
  72. - round detected bandwidth up to nearest 10KB
  73. - client software not upload descriptor until:
  74. - you've been running for an hour
  75. - it's sufficiently satisfied with its bandwidth
  76. - it decides it is reachable
  77. - start counting again if your IP ever changes.
  78. - never regenerate identity keys, for now.
  79. - you can set a bit for not-being-an-OR.
  80. - clients choose nodes proportional to advertised bandwidth
  81. - authdirserver includes descriptor and lists as running iff:
  82. - he can connect to you
  83. - he has successfully extended to you
  84. - he has sufficient mean-time-between-failures
  85. - add new "Middleman 1" config variable?
  86. - if torrc not found, exitpolicy reject *:*
  87. ongoing:
  88. . rename/rearrange functions for what file they're in
  89. - generalize our transport: add transport.c in preparation for
  90. http, airhook, etc transport.
  91. For September:
  92. NICK . Windows port
  93. o works as client
  94. - deal with pollhup / reached_eof on all platforms
  95. . robust as a client
  96. . works as server
  97. - can be configured
  98. - robust as a server
  99. . Usable as NT service
  100. - docs for building in win
  101. - installer
  102. - Docs
  103. - FAQ
  104. o overview of tor. how does it work, what's it do, pros and
  105. cons of using it, why should I use it, etc.
  106. - a howto tutorial with examples
  107. o tutorial: how to set up your own tor network
  108. - (need to not hardcode dirservers file in config.c)
  109. . correct, update, polish spec
  110. - document the exposed function api?
  111. - document what we mean by socks.
  112. NICK . packages
  113. . rpm
  114. - find a long-term rpm maintainer
  115. - code
  116. - better warn/info messages
  117. o let tor do resolves.
  118. o extend socks4 to do resolves?
  119. o make script to ask tor for resolves
  120. - tsocks
  121. - gather patches, submit to maintainer
  122. - intercept gethostbyname and others, do resolve via tor
  123. - redesign and thorough code revamp, with particular eye toward:
  124. - support half-open tcp connections
  125. - conn key rotation
  126. - other transports -- http, airhook
  127. - modular introduction mechanism
  128. - allow non-clique topology
  129. Other details and small and hard things:
  130. - tor should be able to have a pool of outgoing IP addresses
  131. that it is able to rotate through. (maybe)
  132. - tie into squid
  133. - buffer size pool, to let a few buffers grow huge or many buffers
  134. grow a bit
  135. - hidserv offerers shouldn't need to define a SocksPort
  136. - when the client fails to pick an intro point for a hidserv,
  137. it should refetch the hidserv desc.
  138. . should maybe make clients exit(1) when bad things happen?
  139. e.g. clock skew.
  140. - should retry exitpolicy end streams even if the end cell didn't
  141. resolve the address for you
  142. - Add '[...truncated]' or similar to truncated log entries (like the directory
  143. in connection_dir_process_inbuf()).
  144. . Make logs handle it better when writing to them fails.
  145. o Dirserver shouldn't put you in running-routers list if you haven't
  146. uploaded a descriptor recently
  147. . Refactor: add own routerinfo to routerlist. Right now, only
  148. router_get_by_nickname knows about 'this router', as a hack to
  149. get circuit_launch_new to do the right thing.
  150. . Scrubbing proxies
  151. - Find an smtp proxy?
  152. . Get socks4a support into Mozilla
  153. - Extend by hostname, not by IP.
  154. - Need a relay teardown cell, separate from one-way ends.
  155. - Make it harder to circumvent bandwidth caps: look at number of bytes
  156. sent across sockets, not number sent inside TLS stream.
  157. - fix router_get_by_* functions so they can get ourselves too,
  158. and audit everything to make sure rend and intro points are
  159. just as likely to be us as not.
  160. ***************************Future tasks:****************************
  161. Rendezvous and hidden services:
  162. make it fast:
  163. - preemptively build and start rendezvous circs.
  164. - preemptively build n-1 hops of intro circs?
  165. - cannibalize general circs?
  166. make it reliable:
  167. - standby/hotswap/redundant services.
  168. - store stuff to disk? dirservers forget service descriptors when
  169. they restart; nodes offering hidden services forget their chosen
  170. intro points when they restart.
  171. make it robust:
  172. - auth mechanisms to let midpoint and bob selectively choose
  173. connection requests.
  174. make it scalable:
  175. - right now the hidserv store/lookup system is run by the dirservers;
  176. this won't scale.
  177. Tor scalability:
  178. Relax clique assumptions.
  179. Redesign how directories are handled.
  180. - Separate running-routers lookup from descriptor list lookup.
  181. - Resolve directory agreement somehow.
  182. - Cache directory on all servers.
  183. Find and remove bottlenecks
  184. - Address linear searches on e.g. circuit and connection lists.
  185. Reputation/memory system, so dirservers can measure people,
  186. and so other people can verify their measurements.
  187. - Need to measure via relay, so it's not distinguishable.
  188. Bandwidth-aware path selection. So people with T3's are picked
  189. more often than people with DSL.
  190. Reliability-aware node selection. So people who are stable are
  191. preferred for long-term circuits such as intro and rend circs,
  192. and general circs for irc, aim, ssh, etc.
  193. Let dissidents get to Tor servers via Tor users. ("Backbone model")
  194. Anonymity improvements:
  195. Is abandoning the circuit the only option when an extend fails, or
  196. can we do something without impacting anonymity too much?
  197. Is exiting from the middle of the circuit always a bad idea?
  198. Helper nodes. Decide how to use them to improve safety.
  199. DNS resolution: need to make tor support resolve requests. Need to write
  200. a script and an interface (including an extension to the socks
  201. protocol) so we can ask it to do resolve requests. Need to patch
  202. tsocks to intercept gethostbyname, else we'll continue leaking it.
  203. Improve path selection algorithms based on routing-zones paper. Be sure
  204. to start and end circuits in different ASs. Ideally, consider AS of
  205. source and destination -- maybe even enter and exit via nearby AS.
  206. Intermediate model, with some delays and mixing.
  207. Add defensive dropping regime?
  208. Make it more correct:
  209. Handle half-open connections: right now we don't support all TCP
  210. streams, at least according to the protocol. But we handle all that
  211. we've seen in the wild.
  212. Support IPv6.
  213. Efficiency/speed/robustness:
  214. Congestion control. Is our current design sufficient once we have heavy
  215. use? Need to measure and tweak, or maybe overhaul.
  216. Allow small cells and large cells on the same network?
  217. Cell buffering and resending. This will allow us to handle broken
  218. circuits as long as the endpoints don't break, plus will allow
  219. connection (tls session key) rotation.
  220. Implement Morphmix, so we can compare its behavior, complexity, etc.
  221. Use cpuworker for more heavy lifting.
  222. - Signing (and verifying) hidserv descriptors
  223. - Signing (and verifying) intro/rend requests
  224. - Signing (and verifying) router descriptors
  225. - Signing (and verifying) directories
  226. - Doing TLS handshake (this is very hard to separate out, though)
  227. Buffer size pool: allocate a maximum size for all buffers, not
  228. a maximum size for each buffer. So we don't have to give up as
  229. quickly (and kill the thickpipe!) when there's congestion.
  230. Exit node caching: tie into squid or other caching web proxy.
  231. Other transport. HTTP, udp, rdp, airhook, etc. May have to do our own
  232. link crypto, unless we can bully openssl into it.
  233. P2P Tor:
  234. Do all the scalability stuff above, first.
  235. Incentives to relay. Not so hard.
  236. Incentives to allow exit. Possibly quite hard.
  237. Sybil defenses without having a human bottleneck.
  238. How to gather random sample of nodes.
  239. How to handle nodelist recommendations.
  240. Consider incremental switches: a p2p tor with only 50 users has
  241. different anonymity properties than one with 10k users, and should
  242. be treated differently.