123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330 |
- 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
- 0.0.9pre5/6: ("Launch" version)
- o "tor --list-fingerprint" to print fingerprint and exit.
- - Oct 20 16:45:10.237 [warn] parse_addr_port(): Port '0' out of range
- o add and document DirPolicy config option
- - clean up parse_*_policy code
- - when you hup, they're not getting re-parsed
- - stop calling a *_policy an exit_policy_t
- - stop calling running-routers running-routers?
- o Replace running-routers with a router-status line that can be used
- without a list of router descriptors.
- o Add a log handler that sends stuff to syslog.
- o Deprecate unofficial configuration abbrevs; make official abbrevs
- only official on the command line.
- - per-month byte allowances.
- N - Based on bandwidth and per-month allowance, choose a
- window within month to be up. Stay up until allowance is
- used. Adjust next month's window based on outcome. Hibernate
- when we're not up.
- R - Hibernate means "stop accepting connections, and start sleeping"
- Implement hibernation. Have a separate
- about-to-start-hibernating state implemented in similar way to
- will shut-down-in-30-seconds state.
- - Rendezvous service bug: can we nail it down?
- R . bandwidth buckets for write as well as read.
- o Make watchdogged clients check cached-directory mtime to avoid
- fetching directory in a tight loop.
- . Pure C tor_resolve
- o Implement it; socks4a only is fine for now.
- N - Make it build on win32
- N/R - Make it not link with zlib and openssl.
- N - RPMs
- N - Windows installer
- - Review website; make important info more prominent.
- Beyond 0.0.9:
- - Check getrlimit(RLIMIT_[N]OFILE), sysconf(OPEN_MAX) on start-up, and
- warn if we're running as a server with a low limit.
- - Implement If-Modified-Since for directories.
- 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
- - Skeleton only.
- - Implement parts along with 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 - learn from ben about his openssl-reinitialization-trick to
- rotate tls keys without making new connections.
- - (Roger grabs Ben next time he sees him on IRC)
- - 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).
- D nt services on win32.
- - 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)
- - make loglevel info less noisy
- - 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
- . Switch dirservers entries to config lines:
- o read in and parse each TrustedDir config line.
- o stop reading dirservers file.
- o add some default TrustedDir lines if none defined, or if
- no torrc.
- o remove notion of ->is_trusted_dir from the routerlist. that's
- no longer where you look.
- o clean up router parsing flow, since it's simpler now?
- o when checking signature on a directory, look it up in
- options.TrustedDirs, and make sure there's a descriptor
- with that nickname, whose key hashes to the fingerprint,
- and who correctly signed the directory.
- o when fetching a directory, if you want a trusted one,
- choose from the trusteddir list.
- o which means keeping track of which ones are "up"
- ? if you don't need a trusted one, choose from the routerinfo
- list if you have one, else from the trusteddir list.
- * roger will do the above
- - 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.
- 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
- - installer, including all needed libs.
- - Docs
- . FAQ
- o overview of tor. how does it work, what's it do, pros and
- cons of using it, why should I use it, etc.
- - 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
- * roger add to wiki of requests
- . correct, update, polish spec
- - document the exposed function api?
- o document what we mean by socks.
- N . packages
- . rpm
- * nick will look at the spec file
- - find a long-term rpm maintainer
- * roger will start guilting people
- - code
- - better warn/info messages
- o let tor do resolves.
- o extend socks4 to do resolves?
- o make script to ask tor for resolves
- - 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
- . 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.
- - Separate running-routers lookup from descriptor list lookup.
- - Resolve directory agreement somehow.
- - 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.
|