mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-23 20:03:31 +01:00
107 lines
4.1 KiB
Plaintext
107 lines
4.1 KiB
Plaintext
[First four are all equally first.
|
|
Others follow in order of priority.]
|
|
|
|
Patch well-known proxies to make them OR compliant
|
|
Data stream anonymizing, HTTP/FTP (Privoxy, Squid), SMTP, etc.
|
|
Packet Redirector, a la FreeBSD (DNS, authenticated connections, etc.)
|
|
|
|
Deploy and manage open source development site.
|
|
Manage and maintain code, write documentation, design and write
|
|
unit tests, handle patch submissions, make the autoconf work, etc
|
|
|
|
Deploy a widespread network: manage deployment.
|
|
Maintain and distribute directory/network state information etc. Keep
|
|
operators and users happy.
|
|
|
|
Test OR network for reliability and performance, with and without
|
|
mechanisms for throttling, congestion control, padding, load balancing
|
|
if applicable, etc.
|
|
Use httperf and webload to get some performance stats
|
|
Modify code as dictated by testing.
|
|
|
|
Develop rendezvous points
|
|
Implement reply onions
|
|
Develop location protected servers idea
|
|
|
|
Enhance router twins to do load balancing as well as DoS prevention
|
|
|
|
Develop and deploy automated reputation management, directory servers,
|
|
and directory/network state monitoring.
|
|
|
|
---
|
|
|
|
debian / red hat spec file
|
|
handle starting things as a system daemon
|
|
transition addr to sin_addr
|
|
get proxy to choose the same conn if it's open
|
|
|
|
Obvious things I'd like to do that won't break anything:
|
|
|
|
* Abstract out crypto calls (done), with the eventual goal of moving
|
|
from openssl to something with a more flexible license.
|
|
|
|
* Test suite. We need one.
|
|
|
|
* Since my OR can handle multiple circuits through a given OP,
|
|
I think it's clear that the OP should pass new create cells through the
|
|
same channel. Thus we can take advantage of the padding we're already
|
|
getting. Does that mean the choose_onion functions should be changed
|
|
to always pick a favorite OR first, so the OP can minimize the number
|
|
of outgoing connections it must sustain?
|
|
|
|
* Figure out what .h files we're actually using, and how portable
|
|
those are.
|
|
|
|
* Exit policies. Since we don't really know what protocol is being spoken,
|
|
it really comes down to an IP range and port range that we
|
|
allow/disallow. The 'application' connection can evaluate it and make
|
|
a decision.
|
|
|
|
* We currently block on gethostbyname at the exit. This is poor. We need
|
|
to set it up so we have a separate process that we talk to. There are
|
|
some free software versions we can use, but they'll still be tricky.
|
|
|
|
* I'd like a cleaner interface for the configuration files, keys, etc.
|
|
Perhaps the next step is a central repository where we download router
|
|
lists? We can aim to make use of the directory servers that Mixminion
|
|
deploys.
|
|
|
|
* ORs should rotate their link keys periodically. Later.
|
|
|
|
* The parts of the code that say 'FIXME'
|
|
|
|
* Clean up the number of places that get to look at prkey. Later.
|
|
|
|
* Circuits should expire sometime, say, when circuit->expire triggers?
|
|
Later.
|
|
|
|
|
|
|
|
|
|
Non-obvious things I'd like to do:
|
|
|
|
(Many of these topics are inter-related. It's clear that we need more
|
|
analysis before we can guess which approaches are good.)
|
|
|
|
* Currently when a connection goes down, it generates a destroy cell
|
|
(either in both directions or just the appropriate one). When a
|
|
destroy cell arrives to an OR (and it gets read after all previous
|
|
cells have arrived), it delivers a destroy cell for the "other side"
|
|
of the circuit: if the other side is an OP or App, it closes the entire
|
|
connection as well.
|
|
|
|
But by "a connection going down", I mean "I read eof from it". Yet
|
|
reading an eof simply means that it promises not to send any more
|
|
data. It may still be perfectly fine receiving data (read "man 2
|
|
shutdown"). In fact, some webservers work that way -- the client sends
|
|
his entire request, and when the webserver reads an eof it begins
|
|
its response. We currently don't support that sort of protocol; we
|
|
may want to switch to some sort of a two-way-destroy-ripple technique
|
|
(where a destroy makes its way all the way to the end of the circuit
|
|
before being echoed back, and data stops flowing only when a destroy
|
|
has been received from both sides of the circuit); this extends the
|
|
one-hop-ack approach that Matej used.
|
|
|
|
* Reply onions. Hrm.
|
|
|