[tor-dev] Fwd: HTTPS Server Impersonation project
Akshay Hebbar Y.S.
akshayhebbarys at gmail.com
Wed Apr 24 17:01:35 UTC 2013
I wish to do the project 'HTTPS Server Impersonation' as a GSoC project
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
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
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
2. Provide a public key while giving the bridge address. I.e. When someone
requests a bridge
[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
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
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.
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
Please correct me wherever I'm wrong and please give me suggestions to
Akshay Hebbar Y S
6th sem, PESIT-CSE
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tor-dev