<div dir="ltr"><span style="color:rgb(80,0,80)">Hi,</span><br><div class="gmail_quote"><div dir="ltr"><div><div><div class="gmail_quote"><div dir="ltr"><div><br></div><div>I wish to do the project 'HTTPS Server Impersonation' as a GSoC project this year. </div>

<div>For that, I propose an approach for implementation.</div>
<div><br></div>
<div>I would like to use Nginx as reverse proxy. Because nginx is very widely used and it is </div><div>known for its high performance, stability and low resource consumption. Once this is used, </div><div>this will become the interface for Bridges. All connections to the bridge will be listened on port 443.</div>



<div><br></div><div>Two back-end servers for this reverse proxy :</div><div>1. Tor itself</div><div>2. Web server</div><div><br></div><div>A special module has to be written for handling the requests. Once the request is authenticated, </div>


<div>it will be sent to tor process. Otherwise, it will be sent to web server and suitable response is </div><div>sent back.</div>
<div><br></div><div>Once the new tor client finishes its handshake, its IP address will be mapped to Tor in nginx </div><div>'Load Balancer'. Further requests from that IP address will be sent to the Tor directly.</div>


<div>
<br></div><div><br></div><div>How does a bridge distinguish between Tor client and attacker?</div><div>For this, I need suggestions to select one among the following.</div><div>1. Use AUTHORIZE and AUTHORIZED cells as discussed in proposals #187 and #189</div>



<div>2. Provide a public key while giving the bridge address. I.e. When someone requests a bridge </div><div>    address, provide</div><div><span style="white-space:pre-wrap">   </span>[IP ADDRESS] + [PORT] + [PUBLIC KEY] [ here port = 443 ]</div>



<div>Once the client gets the public key of bridge, it can encrypt its data send to bridge. Bridge </div><div>uses its private key to decrypt the message, and hence only bridge can decrypt the message.</div><div>If the message received has proper headers it will be sent to tor, otherwise it will go to the </div>

<div>default web server.</div>
<div><br></div><div><br></div><div>What will the web server contain?</div><div>Web Server will have some pages which makes the website look like 'online storage site' or </div><div>'Online gaming site' or 'social networking site' or something like that. Because a passive attacker </div>


<div>can wonder what the client is sending/receiving from a website which looks like 'blog'!</div>
<div><br></div><div><br></div><div>Hence from the above discussion, we can achieve the goals of project:</div><div><br></div><div>a. Impossible for a passive attacker who examines only a few packets at a time to distinguish </div>


<div>   Tor->Bridge traffic from an HTTPS client talking to an HTTPS server</div>
<div>        Tor client -> bridge connection will be TLS. So he can't distinguish       </div><div><br></div><div>b. Impossible for an active attacker talking to the server to tell a Tor bridge server from a regular HTTPS server</div>



<div>        Every ill-formed request will be handled by Web server.</div><div><br></div><div>c. Against MITM attack</div><div>        If AUTHORIZE and AUTHORIZED cells are used, I need some help in making it preventing MITM attack.</div>



<div>        If method 2 is used for authentication, MITM attack can be easily prevented. Because even though </div><div>the attacker receives the packet, he can't decrypt the message since he doesn't have key for decrypting it. </div>


<div>Tor client sends this message along with its public key. Hence the bridge can encrypt and send back its </div><div>response. Once the TLS connection is established  then attacker will behave like hop in communication</div>



<div><br></div><div>d. Code changes to tor</div><div><span style="white-space:pre-wrap">    </span>It will be minimum and we just need to implement authorization code.</div><div><br></div><div>e. Efficiency</div><div><span style="white-space:pre-wrap">        </span>Once the new client completes its handshake, its IP address will be added to whitelist. Any packets </div>


<div>from a client which is in whitelist will not be authenticated by the handlers in nginx. It will be directly sent to </div><div>Tor process.</div>
<div><br></div><div><br></div><div>Please correct me wherever I'm wrong and please give me suggestions to improve it.</div><div><br></div><div>Thank you</div></div>
</div></div></div></div></div><div><br></div>-- <br><div dir="ltr"><div><font face="arial, helvetica, sans-serif">Akshay Hebbar Y S<br></font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">6th sem, PESIT-CSE</font></div>

</div>
</div>