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?

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

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

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.

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'!

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.

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.

Please correct me wherever I'm wrong and please give me suggestions to improve it.

Thank you