Re: Anonymous Anonymity - Request For Comments
Take a look at Tor.
http://tor.eff.org/
One of the biggest problems with Tor is bandwidth disparity.
On 7/17/05, Gandalf The White <gandalf@xxxxxxxxxxx> wrote:
> Greetings and Salutations:
>
> I realize that this is not specifically a Bugtraq issue, but I have posted
> this to Usenet to the Privacy forums and received little to no response. I
> also consider Bugtraq to be the haven of the most premier security analysts
> available on "The Internet". I would appreciate your comments on the below
> and request that you reply directly to my e-mail address.
>
> Thank you
>
> Ken
>
> Anonymous Anonymity - Request For Comments
>
> "I think paranoia can be instructive in the right doses. Paranoia is a
> skill." - John Shirley
>
> This document is available / updated at the following:
> http://digital.net/~gandalf/Anonymous_Anonymity.htm
>
> I would like to first ask the community to read this and comment on the
> "Issues" section. I am struggling with the how to fix the issues presented.
> If you can conceive a better way to fix the first issue I would appreciate
> that input. If there is a solution that is already well known, please tell
> me. Thanks.
>
> Table Of Contents:
> 1) Abstract
> 2) High Level Description
> 3) Description
> 4) Issues
>
> Abstract:
> The current state of anonymous proxies do not provide adequate protection
> for the entity wishing to preserve their anonymity. Anonymous remailers and
> their ISP's have had court orders to have their logs subpoenaed in court
> (i). There is also a "trust" that the anonymous proxy is truly anonymous.
>
> Given that Country "C" restricts access to certain sites on "The Internet"
> located in country "A". Also given that country "C" wishes to gain
> knowledge of which of its citizens are trying to access restricted sites,
> country "C" could set up anonymous proxies in country "N" to monitor its own
> citizens. In addition if country "C" wished to monitor already popular
> anonymous sites for traffic, they could install a employee in the offices of
> the ISP that serves the popular anonymous site and have that employee
> surreptitiously monitor the traffic going to / leaving that site.
>
> Proposed is a truly anonymous system wherein no one entity has a complete
> picture of the transaction. This system can be installed on a corporate LAN
> (Local Area Network) to allow anonymous access of "sensitive" data (Example
> Anonymous employee suggestions, Human Resources "sensitive" procedures /
> documentation (medical forms, complaint procedures)) or it can be installed
> on "The Internet".
>
> I have seen the statement "Information Wants to Be Free". I would revise
> that statement to "Information Will Be Free". The information does not care
> one way or the other. But humans, simply by their curiosity and need to
> explore ideas will make the information free.
>
> High Level Description:
>
> The software will facilitate the transfer of files (HTTP, FTP, etc.) between
> two computers using anonymous proxies. Every machine will have "the least"
> amount of knowledge to make the transfer possible. One computer (the end
> point) will have access to the data and will know the intermediary proxy but
> will not know what computer the file is ultimately destined for. Another
> computer (the intermediary server or the intermediary proxy) will know what
> two computers the file is being transferred between but will not know the
> contents of the file. The last computer (The destination / anonymous
> machine) will know what the file is and who the proxy is, but not where the
> file is coming from.
>
> When the software is launched, it decides how much bandwidth is available
> for the connection. If it is a low bandwidth then the machine will perform
> the services of an Intermediate Proxy or End Point. If high bandwidth then
> the machine can perform as a Intermediary Server and / or as a Intermediary
> Proxy. This information is only known by the machine that runs the
> software, it is not told to any other computer. This way nobody know if a
> computer is a server or just a transfer agent.
>
> Connections are made to other computers, requests are sent out for
> additional connections until "enough" (depending on bandwidth) connections
> are made. Scalability is not an issue, as connections / servers are
> overloaded traffic will simply be dropped or passed onto other servers that
> are not as loaded.
>
> Searches are passed to all connected machines. If the operator makes a
> selection then that data is transferred to the machine. Searches are
> performed via full URI Scheme (ii) request, by words or phrases contained in
> the file or by filename (or parts thereof). Files retrieved (either from
> "The Internet" or from another machine) are saved in cache on each machine.
> When the file cache is full, the files that haven't been accessed for the
> longest time are deleted. This allows for a "shadow" Internet, sites that
> are censored or deleted are still available via the Anonymous Anonymity
> network.
>
> I have looked at The Freenet Project (iii), and they deserve the credit in
> this project for the idea of a "shadow" Internet, but the Anonymous
> Anonymity Network is fundamentally different. On The Freenet Project web
> pages are published only on the The Freenet Project (and does not allow for
> searching), the Anonymous Anonymity Network allows for searching of not only
> files on the Anonymous Anonymity Network but also the anonymous transfer of
> files into the Anonymous Anonymity Network from "The Internet", thus
> connecting "The Internet" with the Anonymous Anonymity Network. Also, the
> files do not have to be passed from node to node to get to the final
> destination (as in The Freenet Project), they are fetched and sent (via one
> hop) to the final requestor.
>
> Detailed Description:
> There are up to five devices involved in each transaction.
> 1) Destination Machine - The machine that wishes to remain anonymous
> 2) Intermediary Server.
> 3) Intermediary Proxy.
> 4) End point - HTTP anonymous Proxy or file server
> 5) The (HTTP, FTP, NNTP, etc) server that the Anonymous Machine wishes to
> reach.
>
> With this anonymous network, as with the original design of "The Internet",
> there is no central server. The software is initiated on the users machine.
> The bandwidth is detected:
> 1) "Low Bandwidth" - Less than 512 kilobits / second the machine establishes
> itself mainly as a Intermediary Proxy / End Point.
> 2) "High Bandwidth" - Greater than 512 kilobits per second and TCP port 80
> inbound allowed, the machine establishes itself mainly as a Intermediary
> Server.
>
> All connections / communications will use the HTTPEncode encoding.
> HTTPEncode uses the same idea as UUEncode with a slight difference. Whereas
> UUEncode takes binary data and encodes it into "plain text", HTTPEncode
> takes that binary data one step further. The binary data is not only
> encoded to ASCII characters, the HTTPEncode will create HTTP wrappers that
> add HTTP tags to the beginning and end of the data, and throw in random HTML
> tags inside the data. The encoding will also redistribute the character
> count so that the end product has approximately the same character
> distribution as "normal" HTML pages. This is to avoid transport layer -->
> application layer firewalls that look for tunneling over port 80.
>
> When the software is installed the user is asked if they have any filtering
> software that blocks what sites they are able to go to / monitors what sites
> they go to. If they do then their machine is not allowed to be an end point
> that fetches "fresh" web pages. Any firewall devices will have to be set up
> to allow inbound port 80 (or port "X", user defined (since some ISP's block
> port 80)) connections. If this cannot be done then this machine is
> primarily a outbound / Intermediary Proxy connect machine.
>
> The software then attempts connection to a Intermediary Server. The IP
> address of an initial intermediary server can be entered manually or
> downloaded from a web site. The IP addresses are checked against WhoIs or
> ARIN to see if they are geographically diverse. IPv6 will make this process
> easier because it addresses according to the location of the machine.
> Servers that are "farthest away" will be chosen over servers that are
> "close". Intermediary servers should have port 80 open as an inbound
> connection so that they appear to be another web server. If the machine has
> determined that it has the capabilities to be a Intermediary Server then it
> should allow connections to itself as a Intermediary Server. The machine
> should also search for other Intermediary Servers so that requests are
> distributed between many servers. Note: If inbound port 80 cannot be
> established then that machine can still act as a server by making the port
> 80 outbound connection when asked to by another machine (see next paragraph
> handing off to another server). Obviously when the port 80 outbound
> connection is made two way communications can then ensue.
>
> If a server has too many nodes, it should pass any new connections off to
> another server and notify the machine that is trying to connect of this
> handoff so that it can establish a direct connection to the other server.
> If an Intermediary Proxy is using more than 50% of its bandwidth proxying
> connections, then additional connection requests should be denied.
>
> All connections / communications should be encrypted with the exception of
> the request. Each connection creates a unique encryption public/private key
> pair for use in communication (this is so that the user cannot be identified
> by using the same public key over and over again).
>
> Routing - Since data is routed node to node, the routing will not allow
> least cost (efficient) routing. Just individual direct connections will be
> in the routing table (IP Address / Search Request). Data would be "routed"
> by each node keeping a table of incoming IP Address / search request hashes
> paired with outgoing IP Address / search request hashes. The route back
> being (of course) the path of pairs of IP Address's and search request
> hashes that are related. This gives each node the "least knowledge" of the
> source and destination. An Intermediary Server should not know whether a
> node that is connected is another Intermediary Server or a Anonymous Machine
> or an End Point.
>
> Searches can be of the form:
> 1) URI Scheme request (http, https, ftp, gopher, file, etc)
> 2) File Name (or parts of file name)
> 3) Data in file (words, phrases, ANDed words or ORed words)
>
> The search request is added to the public key and hashed, this is to make
> each search unique. This is referred to as the search hash. The search
> with a unique public key and search hash is passed from the Anonymous
> Machine to all Intermediary Servers. When a search request is seen, a
> lookup of the search hash is made on the server in the "already known
> searches" search table and if the hash of the search matches a already
> received search, the search is dropped (this search has already been through
> this machine). If the search is not dropped, the search hash is stored in a
> lookup table with the IP Address that the search was received from. The
> Intermediary Server passes the entire search to all Intermediary Servers
> Anonymous Machines and End Point machines it knows except for the machine
> the search request came from (the server doesn't know what "kind" of machine
> it is connected to). If an end point machine can satisfy the request / has
> matches for the request then that data relating to the request is encrypted
> using the public key and passed back to the Intermediary Server with the
> search response hash number. The response data from the end point machine
> is the URI, the URI hash, the size of the file and the date of the file
> (when the file was created). When positive responses are received then
> those responses are returned via the routing (above) to the IP Address that
> initiated the request.
>
> The Anonymous Machine then (by operator choice or by random) chooses a one
> of the hashes to act on the request. If no node has the URI available in
> cache then a node that can connect to the URI is chosen. If any node
> returns a hash indicating that they have the file, then a second search
> request is sent out via another connection (i.e do not send the hash request
> out via the server that the original search response came in from) using the
> hash as the search request. Nodes that have that hash return the hash and
> hash dictionary (see below). If the file is large, this search hash / hash
> dictionary will allow the Anonymous Machine to transfer parts of the file
> from many sources. The Anonymous Machine will also be able to offer
> portions of the file out when as they are received if other machines are
> looking for that same file. Note: To further obfuscate the "real" requests,
> Anonymous Machines should take random incoming requests / pick random words
> and send them out as fake requests to Intermediary Servers. Results from
> these fake requests are, of course, ignored.
>
> When the search table fills, requests are dropped in a FIFO manner for a
> specific IP Address. If someone tries to flood the network with requests to
> empty the tables, only the IP Address they are connected to will suffer, not
> other IP Address's.
>
> Note: The positive responses to the search may be a form of "I can act as
> your proxy for that URL, but I don't have the URL" or "I have the entire
> URL, and this is the last date that I accessed that page plus here is the
> hash of the data on that page". The operator can choose whether they want a
> copy (possibly stale) or if they want to chose a proxy that can get the
> current page. All links on that page are different files that are searched
> / requested for. Additionally (in this manner) the Anonymous Anonymity
> network could host its own WWW network where those pages were only
> accessible to someone connected to the Anonymous Anonymity network, or via a
> machine proxying for the Anonymous Anonymity network.
>
> When the Anonymous Requester receives a request that is acceptable, a
> connection request is sent along the path that is in the response data using
> the IP Address / search hash connection pair generated in the previous
> paragraph. This connection request has a new public key associated with the
> request. The Intermediary Proxy Server sends out a request on all
> connections for a proxy and randomly chooses one of those responses and
> requests that Intermediary Proxy IP address. The IP address of this
> Intermediary Proxy is sent to the path of both the End Point machine and the
> Anonymous Requester.
>
> The End Point machine and the Anonymous Requester set up connections with
> the Intermediary Proxy on TCP Port 80. Again, data is encrypted and then
> HTTPEncoded. The Intermediary Proxy knows the source and destination, but
> not what data is being exchanged. When the data exchange is complete the
> connection is terminated.
>
> The whole idea behind this network is for each node to know the minimum
> information for the system to work. The less a node knows the less
> information that can be pieced together to get the whole picture. In
> training for Security Clearances the quote goes something like "Unclassified
> information can easily be combined to reveal classified information."
>
> File name:
> The file name is retuned with a SHA-2 hash and a SHA-2 hash dictionary. The
> SHA-2 hash is just a SHA-2 hash of the file. The SHA-2 Hash Dictionary is a
> SHA-2 hash of "X" bytes of the file (where "X" is size of file / 1023 and
> where "X" is greater than 32 Kbytes). The Anonymous Machine would request
> chunk "y" of the file from the End Point. These requests would continue
> until the Anonymous Machine has all the chunks it needs or until the
> connection is broken. In this manner the Anonymous Machine could be
> requesting parts of a particular file while also sending out parts of a
> particular file to other users. If the file is less than 32 MBytes then the
> hash table would be 32 Kbytes chunks of the file with the number of hashes
> indicated in the hash table. This hash allows (in the case, for example, of
> large FTP URI Scheme requests) requests to be made of parts of the file
> being requested if it is a large file. The file hash and the hash segment
> of the file would be requested, therefore several machines could be sending
> parts of the file to the anonymous requester at the same time.
>
>
> Issues:
> 1) The issue with a party owning the server and the anonymous proxier and /
> or the intermediary machine. This is essentially the Man In The Middle
> attack. The attacker "owns" the server in the middle which directs the
> anonymous machine to proxies and end point devices that it also controls,
> therefore the server knows the anonymous machine and what they are
> requesting. Same thing if the attacker wants to find out what files are on
> the end point machine, they act like the anonymous requester and the
> intermediary servers / proxies and make requests. While this issue is not
> completely solved by the above scheme, it is mitigated by the Anonymous
> Machine searching on the hash after the initial responses are received.
> Even if the server is acting as a man in the middle, the server would need
> to maintain a table of URIs / hashes returned. As the network grows this
> table would become huge.
>
> 2) HTTPS connections. The HTTPS transfer would require several data
> requests that would require the end point to serve up multiple pages to the
> anonymous requester. the Man In The Middle attack would be mitigated by the
> fact that the anonymous requester would be able to verify the SSL
> certificate of the site that they are visiting.
>
> 3) Abuse of the anonymous system by someone who is stalking, etc. The IP
> address of the proxier is the address that shows up on the logs and stalking
> / spamming / etc. would be blamed on whoever owns the IP Proxier address.
>
> 4) Not being able to make HTTP requests that divulge the end stations IP
> address. (Example http://www.whatismyip.com/ )
>
> 5) Creation of HHTPEncode algorithm that ensures even letter distribution /
> HTML format of data.
>
> 6) Spammers - Assuming that the this system is programmed in open source,
> you will (at some time) have some smart spammer figure out a way to redirect
> HTTP requests to them and they will serve out their own spamvertized pages.
> Same with data files, nodes could put out data files that have nothing to do
> with the request made. A local file should be kept where the user can
> ignore all responses from a specific connection or ignore a specific hash.
> The file would be only locally significant because if it became global then
> nefarious people could "poison" sites that are serving out good information
> and say that these are "bad" sites.
>
> 7) Thomas J. Boschloo wrote "The problem remains, how to download this
> software without drawing attention onto oneself!"
>
> i) Newman, Ron and Copeland, Frank "The Church of Scientology vs. Grady
> Ward" (Specifically "Scientology targets ISPs and anonymous remailers").
> URL: http://www.xs4all.nl/~kspaink/cos/rnewman/grady/home.html Wednesday,
> July 24, 1996 (Accessed July 4, 2005)
> ii) IANA Registry of URI Schemes "Uniform Resource Identifier (URI)
> SCHEMES". URL: http://www.iana.org/assignments/uri-schemes 03 June 2005
> (Accessed July 4, 2005)
> iii) The Freenet Project "The Freenet Project - index - beginner". URL:
> http://freenetproject.org, 04 July 2005
>
>
> I would appreciate any and all comments on the above Anonymous Anonymity
> network. Specifically any solutions to the presented problems or if someone
> has already covered this ground I would appreciate pointers to their work.
>
> Thank you for your comments.
>
> Ken Hollis
>
> ---------------------------------------------------------------
> Do not meddle in the affairs of wizards for they are subtle and
> quick to anger.
> Ken Hollis - Gandalf The White - gand...@xxxxxxxxxxx - O- TINLC
> WWW Page - http://digital.net/~gandalf/
> Trace E-Mail forgery - http://digital.net/~gandalf/spamfaq.html
> Trolls crossposts - http://digital.net/~gandalf/trollfaq.html
> Woodworking For Geeks - http://digital.net/~gandalf/woodmain.htm
>
>
--
Craig
cskelton@xxxxxxxxx