On Wed, Apr 24, 2013 at 1:01 PM, Akshay Hebbar Y.S. akshayhebbarys@gmail.com wrote:

Hi,

I wish to do the project 'HTTPS Server Impersonation' as a GSoC project this year. For that, I propose an approach for implementation.

I would like to use Nginx as reverse proxy. Because nginx is very widely used and it is known for its high performance, stability and low resource consumption. Once this is used, this will become the interface for Bridges. All connections to the bridge will be listened on port 443.

Two back-end servers for this reverse proxy :

1. Tor itself
2. Web server

A special module has to be written for handling the requests. Once the request is authenticated, it will be sent to tor process. Otherwise, it will be sent to web server and suitable response is sent back.

Once the new tor client finishes its handshake, its IP address will be mapped to Tor in nginx 'Load Balancer'. Further requests from that IP address will be sent to the Tor directly.

How does a bridge distinguish between Tor client and attacker?

Wouldn't that happen too late? It's the "load-balancer" front-end that needs to distinguish between clients and attackers; if the attacker traffic is passed to the bridge, then the game is over.

For this, I need suggestions to select one among the following.

1. Use AUTHORIZE and AUTHORIZED cells as discussed in proposals #187 and

#189

As a probing-resistence method, this is problematic: an attacker can make a partial AUTHORIZE cell that a real HTTPS server would reject as bad HTTP, but which a Tor server couldn't reject without seeing the whole cell. So you couldn't use these cells as is, but you might be able to encode the protocol in an HTTP header or something.

2. Provide a public key while giving the bridge address. I.e. When someone

requests a bridge address, provide [IP ADDRESS] + [PORT] + [PUBLIC KEY] [ here port = 443 ] Once the client gets the public key of bridge, it can encrypt its data send to bridge. Bridge uses its private key to decrypt the message, and hence only bridge can decrypt the message. If the message received has proper headers it will be sent to tor, otherwise it will go to the default web server.

Something like this might work too, so long as it's in an HTTP header which a regular HTTPS server would simply reject and ignore.

What will the web server contain? Web Server will have some pages which makes the website look like 'online storage site' or 'Online gaming site' or 'social networking site' or something like that. Because a passive attacker can wonder what the client is sending/receiving from a website which looks like 'blog'!

See the section at the end of Tor proposal 203 (https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/203-https-fro... ) for more ideas on this.

Hence from the above discussion, we can achieve the goals of project:

a. Impossible for a passive attacker who examines only a few packets at a time to distinguish Tor->Bridge traffic from an HTTPS client talking to an HTTPS server Tor client -> bridge connection will be TLS. So he can't distinguish

b. Impossible for an active attacker talking to the server to tell a Tor bridge server from a regular HTTPS server Every ill-formed request will be handled by Web server.

If every ill-formed request is handled by the web server, an attacker could probe for Tor by sending a well-formed but incorrect AUTHORIZE cell. Or by sending an incomplete authorize cell: we couldn't rejected it until we see the whole thing, but a real web server would reject it much sooner.

c. Against MITM attack If AUTHORIZE and AUTHORIZED cells are used, I need some help in making it preventing MITM attack. If method 2 is used for authentication, MITM attack can be easily prevented. Because even though the attacker receives the packet, he can't decrypt the message since he doesn't have key for decrypting it. Tor client sends this message along with its public key. Hence the bridge can encrypt and send back its response. Once the TLS connection is established then attacker will behave like hop in communication

d. Code changes to tor It will be minimum and we just need to implement authorization code.

e. Efficiency Once the new client completes its handshake, its IP address will be added to whitelist. Any packets from a client which is in whitelist will not be authenticated by the handlers in nginx. It will be directly sent to Tor process.

THis sounds like a questionable idea; we're trying to resist ISP-level adversaries who can forge IP addresses. Also, dynamic IP exists, so you don't want to be whitelisting an IP long-term.

best wishes,