[tor-dev] Fwd: HTTPS Server Impersonation project

[Akshay Hebbar Y.S.]

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?
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

-- 
Akshay Hebbar Y S

6th sem, PESIT-CSE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20130424/a69fddef/attachment.html>