Traffic analysis from upstream sniffers trivially breaks this system. TLAs
have been known to place boxes upstream of 'interesting' sites for years.
End to end crypto is needed, as is real security (i.e. physical) of the
nodes, else you get an "really enhanced" NIC card added some dark night.
I'd say it depends on your thread level.
At 04:40 PM 4/24/00 -, lcs Mixmaster Remailer wrote:
What do you think of a program which works as follows.
It is a TCP/IP redirector, but it is designed to protect the anonymity
of web servers. People voluntarily run this program on their systems.
A server which wants to be anonymous connects to one of these redirectors,
and gives it a command telling it to listen on port X, and any incoming
connections on that port should be forwarded to port Y on the requesting
host.
For example: Alice wants to run a server anonymously, so she connects to
Bob's computer and gives his redirection program the command to listen
on port 12345 (say) and when connections occur there, to forward them
to port 80 on Alice's machine.
Then she can publish her server URL as http://www.bob.com:12345.
When Bob's server receives a connection on that port, he initiates an
outgoing connection to port 80 on Alice's machine. He then goes into
bidirectional mode and sends data back and forth.
As far as the client is concerned, he is connection to port 12345 on
Bob's machine. But as far as Alice's machine is concerned, she gets
connections on port 80. Neither the user's browser nor Alice's web
server have to be changed; the additional connection step is transparent
to them.
In addition, chained connections can be created. Bob's redirector maps
incoming port 12345 to port 80 on Alice's host. Alice can then ask
Carol's redirector to map incoming port 54321 to port 12345 on Bob's
computer. Then the URL http://www.carol.com:54321 will still get to
Alice's host, via two hops. In this way Carol does not know the actual
location of the server.
If Alice had to connect directly to Carol to set this up, it would reveal
her host's identity to Carol. So the redirector also has a "transparent"
mode for setting up chained connections. Alice connects to Bob's machine
and tells him to listen on port 12345. She then asks Bob's redirector
to connect her to Carol's redirector and go into transparent mode.
Now she can communicate with Carol's redirector via Bob. She can give
it commands without Carol seeing Alice's address.
Abuse of redirectors is always a concern. Hackers might use redirectors
to conceal their locations when attempting to break into systems.
This is avoided in two ways. First, redirection requests can only be set
up for a target IP equal to the requesting machine's IP. Alice can ask
Bob to forward data to her machine, but not to anyone else's. When she
connects to Carol via Bob's transparent connection, she can ask Carol
to forward to Bob, but not to anyone else. Hence it is not possible to
get the redirector to connect to arbitrary addresses.
Second, the transparent-connection feature (used for setting up chains)
is also limited so that it can't be used to facilitate anonymous hacking
into systems. The redirectors give a one-line identification when they
are connected to. When one redirector is asked to forward a connection to
another in transparent mode, it looks for that one-line response. If it
is not present, the redirector won't send any data along that connection.
Therefore redirectors in transparent-connection mode will only connect
to other redirectors.
The current system does rely on the integrity of the first redirector
in the chain (Bob's, in the example above). Bob sees the entire chain
that Alice sets up. In the other direction (towards Alice, rather
than away from her), there is anonymity; each redirector knows only the
address of the next redirector in the chain. But outgoing from Alice,
each redirector knows the whole remainder of the chain.
Since attackers would typically be starting from the far end of the chain
(the client end), this is the direction in which we most need protection.
Only if we got to the point where people were running rogue redirectors
would the information leakage in the other direction be a concern.
Ideally crypto could be used to hide this information. Alice could
set up an encrypted connection to each redirector in the chain as she
sets it up. She would connect to Bob and tell him to listen on a port.
Then she would connect to Carol via Bob, but negotiate an encrypted
connection with Carol before giving commands to her. Bob would not know
which port Carol was told to listen on, nor what other redirectors Alice
communicated with beyond Carol. In this way each redirector would know
only its neighbors in the chain.
Is there an appropriate role for crypto in the incoming connections from
clients? It would seem not, if each redirector only knows its neighbors
as described above. Sending the data through the pipeline unchanged
