123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288 |
- Legend:
- SPEC!! - Not specified
- SPEC - Spec not finalized
- NICK - nick claims
- ARMA - arma claims
- - Not done
- * Top priority
- . Partially done
- o Done
- D Deferred
- X Abandoned
- Tor 0.0.9rc1:
- o Weasel wants to say 50GB rather than 50000000 in config ints.
- o Nick wants to say "1 hour" instead of 3600 in config ints.
- o Better hibernation flexibility
- o Add hibernation intervals for weeks, days.
- o Start at a time other than 0:00 GMT.
- o Document
- o Integrate NT service patch
- . make loglevels info,debug less noisy
- Beyond 0.0.9:
- - server descriptor declares min log level, clients avoid servers
- that are too loggy.
- N - Clean up NT service code
- N - OS X package (and bundle?)
- - controller should have 'getinfo' command to query about rephist,
- about rendezvous status, etc.
- - allow transition from ORPort to !ORPort, and back
- R . bandwidth buckets for write as well as read.
- - Limit to 2 dir, 2 OR, N SOCKS connections per IP.
- - Implement If-Modified-Since for directories.
- - Make more configuration variables into CSVs.
- N - Handle rendezvousing with unverified nodes.
- - Specify: Stick rendezvous point's key in INTRODUCE cell.
- Bob should _always_ use key from INTRODUCE cell.
- - Implement.
- R - figure out enclaves, e.g. so we know what to recommend that people
- do, and so running a tor server on your website is helpful.
- - Do enclaves for same IP only.
- - Resolve first, then if IP is an OR, connect to next guy.
- N . the user interface interface
- - Implement a trivial fun gui.
- N - add ipv6 support.
- - Spec issue: if a resolve returns an IP4 and an IP6 address,
- which to use?
- N&R - Update Spec
- R X learn from ben about his openssl-reinitialization-trick to
- rotate tls keys without making new connections.
- - Do something to prevent spurious EXTEND cells from making middleman
- nodes connect all over. Rate-limit failed connections, perhaps?
- - christian grothoff's attack of infinite-length circuit.
- the solution is to have a separate 'extend-data' cell type
- which is used for the first N data cells, and only
- extend-data cells can be extend requests.
- - have a pool of circuits available, cannibalize them
- for your purposes (e.g. rendezvous, etc).
- - Once we have a trusted directory on port 80, stop falling back to
- forbidden ports when fascistfirewall blocks all good dirservers.
- o fix sprintf's to snprintf's?
- . Make intro points and rendezvous points accept $KEYID in addition
- to nicknames.
- o Specify
- o Implement parsing
- - Generate new formats (Not till 007 is dead)
- - Facility to automatically choose long-term helper nodes; perhaps
- on by default for hidden services.
- o Make command-line strict about checking options; make only certain
- option prefixes work.
- - Rate-limit OR and directory connections overall and per-IP and
- maybe per subnet.
- D put expiry date on onion-key, so people don't keep trying
- old ones that they could know are expired?
- * Leave on todo list, see if pre3 onion fixes helped enough.
- D should the running-routers list put unverified routers at the
- end?
- * Cosmetic, don't do it yet.
- D make advertised_server_mode() ORs fetch dirs more often.
- * not necessary yet.
- D Add a notion of nickname->Pubkey binding that's not 'verification'
- * eventually, only when needed
- D ORs use uniquer default nicknames
- * Don't worry about this for now
- D Handle full buffers without totally borking
- * do this eventually, no rush.
- D if destination IP is running a tor node, extend a circuit there
- before sending begin.
- * don't do this for now. figure out how enclaves work. but do
- enclaves soon.
- - Support egd or other non-OS-integrated strong entropy sources
- more features, complex:
- - password protection for on-disk identity key
- - Have clients and dirservers preserve reputation info over
- reboots.
- * continue not doing until we have something we need to preserve
- - round detected bandwidth up to nearest 10KB?
- - client software not upload descriptor until:
- - you've been running for an hour
- - it's sufficiently satisfied with its bandwidth
- - it decides it is reachable
- - start counting again if your IP ever changes.
- - never regenerate identity keys, for now.
- - you can set a bit for not-being-an-OR.
- * no need to do this yet. few people define their ORPort.
- - authdirserver lists you as running iff:
- - he can connect to you
- - he has successfully extended to you
- - you have sufficient mean-time-between-failures
- * keep doing nothing for now.
- - Include HTTP status messages in logging (see parse_http_response).
- blue sky:
- - Possible to get autoconf to easily install things into ~/.tor?
- ongoing:
- . rename/rearrange functions for what file they're in
- - generalize our transport: add transport.c in preparation for
- http, airhook, etc transport.
- o investigate sctp for alternate transport.
- For September:
- N . Windows port
- o works as client
- - deal with pollhup / reached_eof on all platforms
- . robust as a client
- . works as server
- - can be configured
- - robust as a server
- . Usable as NT service
- - docs for building in win
- o installer, including all needed libs.
- - and including privoxy
- - and including a sockscap equivalent
- - Docs
- . FAQ
- - a howto tutorial with examples
- * put a stub on the wiki
- o tutorial: how to set up your own tor network
- o (need to not hardcode dirservers file in config.c)
- o Make tutorial reflect this.
- . port forwarding howto for ipchains, etc
- . correct, update, polish spec
- - document the exposed function api?
- - Document where we differ from tor-design
- . packages
- . find a long-term rpm maintainer
- - code
- - better warn/info messages
- - write howto for setting up tsocks, socat.
- - including on osx and win32
- - freecap handling
- - tsocks
- o gather patches, submit to maintainer
- * send him a reminder mail and see what's up.
- - intercept gethostbyname and others
- * add this to tsocks
- o do resolve via tor
- - redesign and thorough code revamp, with particular eye toward:
- - support half-open tcp connections
- - conn key rotation
- - other transports -- http, airhook
- - modular introduction mechanism
- - allow non-clique topology
- Other details and small and hard things:
- - tor should be able to have a pool of outgoing IP addresses
- that it is able to rotate through. (maybe)
- - tie into squid
- - hidserv offerers shouldn't need to define a SocksPort
- * figure out what breaks for this, and do it.
- - when the client fails to pick an intro point for a hidserv,
- it should refetch the hidserv desc.
- . should maybe make clients exit(1) when bad things happen?
- e.g. clock skew.
- - should retry exitpolicy end streams even if the end cell didn't
- resolve the address for you
- o Make logs handle it better when writing to them fails.
- o Dirserver shouldn't put you in running-routers list if you haven't
- uploaded a descriptor recently
- . Refactor: add own routerinfo to routerlist. Right now, only
- router_get_by_nickname knows about 'this router', as a hack to
- get circuit_launch_new to do the right thing.
- . Scrubbing proxies
- - Find an smtp proxy?
- . Get socks4a support into Mozilla
- - Need a relay teardown cell, separate from one-way ends.
- - Make it harder to circumvent bandwidth caps: look at number of bytes
- sent across sockets, not number sent inside TLS stream.
- - fix router_get_by_* functions so they can get ourselves too,
- and audit everything to make sure rend and intro points are
- just as likely to be us as not.
- ***************************Future tasks:****************************
- Rendezvous and hidden services:
- make it fast:
- - preemptively build and start rendezvous circs.
- - preemptively build n-1 hops of intro circs?
- - cannibalize general circs?
- make it reliable:
- - standby/hotswap/redundant services.
- - store stuff to disk? dirservers forget service descriptors when
- they restart; nodes offering hidden services forget their chosen
- intro points when they restart.
- make it robust:
- - auth mechanisms to let midpoint and bob selectively choose
- connection requests.
- make it scalable:
- - right now the hidserv store/lookup system is run by the dirservers;
- this won't scale.
- Tor scalability:
- Relax clique assumptions.
- Redesign how directories are handled.
- o Separate running-routers lookup from descriptor list lookup.
- - Resolve directory agreement somehow.
- o Cache directory on all servers.
- Find and remove bottlenecks
- - Address linear searches on e.g. circuit and connection lists.
- Reputation/memory system, so dirservers can measure people,
- and so other people can verify their measurements.
- - Need to measure via relay, so it's not distinguishable.
- Bandwidth-aware path selection. So people with T3's are picked
- more often than people with DSL.
- Reliability-aware node selection. So people who are stable are
- preferred for long-term circuits such as intro and rend circs,
- and general circs for irc, aim, ssh, etc.
- Let dissidents get to Tor servers via Tor users. ("Backbone model")
- Anonymity improvements:
- Is abandoning the circuit the only option when an extend fails, or
- can we do something without impacting anonymity too much?
- Is exiting from the middle of the circuit always a bad idea?
- Helper nodes. Decide how to use them to improve safety.
- DNS resolution: need to make tor support resolve requests. Need to write
- a script and an interface (including an extension to the socks
- protocol) so we can ask it to do resolve requests. Need to patch
- tsocks to intercept gethostbyname, else we'll continue leaking it.
- Improve path selection algorithms based on routing-zones paper. Be sure
- to start and end circuits in different ASs. Ideally, consider AS of
- source and destination -- maybe even enter and exit via nearby AS.
- Intermediate model, with some delays and mixing.
- Add defensive dropping regime?
- Make it more correct:
- Handle half-open connections: right now we don't support all TCP
- streams, at least according to the protocol. But we handle all that
- we've seen in the wild.
- Support IPv6.
- Efficiency/speed/robustness:
- Congestion control. Is our current design sufficient once we have heavy
- use? Need to measure and tweak, or maybe overhaul.
- Allow small cells and large cells on the same network?
- Cell buffering and resending. This will allow us to handle broken
- circuits as long as the endpoints don't break, plus will allow
- connection (tls session key) rotation.
- Implement Morphmix, so we can compare its behavior, complexity, etc.
- Use cpuworker for more heavy lifting.
- - Signing (and verifying) hidserv descriptors
- - Signing (and verifying) intro/rend requests
- - Signing (and verifying) router descriptors
- - Signing (and verifying) directories
- - Doing TLS handshake (this is very hard to separate out, though)
- Buffer size pool: allocate a maximum size for all buffers, not
- a maximum size for each buffer. So we don't have to give up as
- quickly (and kill the thickpipe!) when there's congestion.
- Exit node caching: tie into squid or other caching web proxy.
- Other transport. HTTP, udp, rdp, airhook, etc. May have to do our own
- link crypto, unless we can bully openssl into it.
- P2P Tor:
- Do all the scalability stuff above, first.
- Incentives to relay. Not so hard.
- Incentives to allow exit. Possibly quite hard.
- Sybil defenses without having a human bottleneck.
- How to gather random sample of nodes.
- How to handle nodelist recommendations.
- Consider incremental switches: a p2p tor with only 50 users has
- different anonymity properties than one with 10k users, and should
- be treated differently.
|