Anonymization and Privacy Services Infranet: Circumventing Web Censorship and Surveillance, Feamster et al, Usenix Security Symposium 2002.

Philosophy of Identity Privacy Standard uses of encryption can keep the contents of data private. Privacy concerning location/identity of users is usually ignored Inherently a difficult problem, since location and identity are usually core to routing and delivery.

Tools Anonymizer.com – analogous to anonymous r ing services. –Squid and Zero Knowledge are the same Triangle Boy – volunteer peer-to-peer solution. Peekabooty – sends encrypted requests to a third party intermediary

More tools… Crowds and Onion Routing – users in a large, diverse group are separated from their requests. Freenet – Anonymous content storage and retrieval. Infranet – Steganographic content delivery through cooperating third party server.

Problems with these tools Proxy-based intermediary schemes require the presence of a well-known proxy server, which can be blocked. Any scheme using SSL can be trivially blocked by killing connections with recognized SSL handshakes Encryption alone is not enough to prevent traffic analysis.

Infranet: overall goals Censorship Surveillance Plausible deniability Design goals: –Deniability for requestors (including statistical) –Responder covertness (identifying responders) –Communication robustness (resilience)

Infranet: threat model Passive: –Traffic Analysis –Logging Active – alteration of packets, sessions Impersonation – both of requester and responder

Infranet: system

System Two key entities: –Requester, which sits on the user’s end, and uses a tunnel to a public web server to request censored content. –Responder, which is integrated into a public web server. It fetches censored content, returns it to the requester over a covert channel, and treats all clients as if they were Infranet users.

The tunnel Three abstraction layers: –Message exchange (logical information passed between points) –Symbol construction (alphabet [URL list] specification) –Modulation (mapping between alphabet and message)

Tunnel setup The “Hello” of the protocol is implied by requesting an HTML document. Responder keeps track of user ID implicitly, generates unique URLs Requester sends shared secret with responders public key Responder creates unique modulation function.

Upstream data Requests for censored pages are imbedded in innocent looking HTTP requests Covert modulation achieved through range-mapping.

Downstream data The requester requests an HTML page with embedded images The unimportant bits in the image will be changed to carry encoded content (steganography) Shared secret key used as a pseudo- random number generator to decide which bits carry content

User control The system could be modified to allow the user some control over which URLs get sent: –Multiple URLs map to the same information, user selects which one –User can reject URLs, try to pass the information again

Active attack susceptibility The censor can modify traffic in both directions –It can flip bits in the return images –Insert/remove/reorder links on a page This can be detected and dropped by Infranet; could potentially be fixed with ECC.

More active attack The censor could send data from its own cache –“no-cache” directive will likely be ignored Infranet inherently circumvents this problem by serving unique URLs to each client – no cache hits.

Possible problems page 4 - "One way to distribute software is out-of-band via a CD-ROM or floppy disk. Users can share copies of the software and learn about Infranet responders directly from one another." –This seems to contradict plausible deniability

Possible problems Page 9 - "To join Infranet as a requester, a participant must discover the IP address and public key of a responder.” Can the IP address and public key be determined by a censor by passive analysis of user traffic?

Possible problems page 3 – "Hopefully, a significant number of people will run Infranet responders due to altruism or because they believe in free speech.“ page 11 – “Infranet’s success…depends on the pervasiveness of Infranet responders throughout the web.” –Requisite deployment issue

Possible problems Infranet counters black-list filtering –What about white-list filtering? In terms of plausible deniability, what about telltale software on the user’s machine?

Possible problems The paper states the only way to act as a valid requester, a censor must know the public key Does the censor need to act as a requester to identify responders (and subsequently, block them)? –eg, exploiting unique URLs per user

Anonymous Connections and Onion Routing Paul F. Syverson, David M. Goldschlag, and Michael G. Reed, Naval Research Labratory A simple paper A simple idea

Onion routing: basic idea Users send sensitive data to a proxy/onion router that is securely managed This machine generates a routing path, and encapsulates the data for each node in the path with next-hop information cryptographically. Each time a node is traversed, one of these “layers” of encryption is removed.

Onion: threat model All traffic is visible All traffic can be modified Onion routers may be compromised Compromised routers may cooperate

Acknowledged attacks Modifying or replaying onions will result in the end plaintext either not being delivered or not being readable. It does not result in sensitive information being disclosed or made obvious. But, this implies denial of service vulnerability.

Replay attacks To combat replay attacks, onion routers drop duplicate onions Each router keeps a hash of every onion it passes along Part of section 4: “To control storage requirements, onions are equipped with expiration times.” – absolute times are used in this scheme.

Possible problem Scalability: The number of asymmetric encryption applications is equal to twice the number of hops throughout the path for each packet. On their UltraSPARC, one such encryption took about one tenth of a second.

Questions Have systems such as Infranet beaten localized Internet censorship? Have they improved the situation by making censoring more difficult? Is Onion routing sufficient to protect the participants in arbitrary communication? Would Onion routing be sufficient to protect the source identity in a one-way conversation? The discussed schemes deal with anonymization and privacy as they relate to third parties; has any thing been done to protect privacy concerning second parties?