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 -0000, 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 would
>not seem to reveal more information. If the data is sensitive the server
>can provide an https URL and use SSL to encrypt the channel to the client.
>Are there other considerations that would make crypto useful here?
>
>Finally, there remain questions of utility and safety. Does this software
>provide enough security to be useful? And is it safe for someone to run,
>as they might run a remailer?
>
>The security provided to the final host depends on whether an attacker
>can break down the chain one step at a time. He goes to Elvis and finds
>him forwarding to David, then goes to David and finds him forwarding to
>Carol, and so on. At each step he must use either legal or technical
>means to try to find the next connection. Whether he can do this will
>depend on the resources at his command.
>
>There is also the question of safety for people running redirectors.
>Suppose someone makes DeCSS available but hides their host
>behind a redirector chain. The URL ends up getting published as
>http://www.carol.com:54321. Now the RIAA sends a cease and desist
>order to Carol, whom it assumes to be running a web page offering DeCSS.
>What does she need to do? Is she innocent? Suppose the RIAA produces
>some kind of transcript showing that they connected to her URL and found
>DeCSS. How could she argue that she was not guilty, when the effect
>was exactly the same as if she had truly been running a web server with
>contraband data?
>
>Bottom line: if you had a server with controversial information, would
>you feel that presenting it from behind a chain of this type would
>add safety for you? And, secondly, would you be willing to run such a
>redirector as a service to people who want to protect their anonymity?
>
>This software is written and runs on unix and windows, but does not yet
>have crypto. Any thoughts on whether further development is worthwhile
>would be appreciated.
>
>
>
