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