Re: [tor-dev] Fwd: HTTPS Server Impersonation project

[Nick Mathewson <nickm@xxxxxxxxxxxx>]

On Wed, Apr 24, 2013 at 1:01 PM, Akshay Hebbar Y.S.
<akshayhebbarys@xxxxxxxxx> wrote:
> 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?

Wouldn't that happen too late?  It's the "load-balancer" front-end
that needs to distinguish between clients and attackers; if the
attacker traffic is passed to the bridge, then the game is over.


> For this, I need suggestions to select one among the following.
> 1. Use AUTHORIZE and AUTHORIZED cells as discussed in proposals #187 and
> #189

As a probing-resistence method, this is problematic: an attacker can
make a partial AUTHORIZE cell that a real HTTPS server would reject as
bad HTTP, but which a Tor server couldn't reject without seeing the
whole cell.  So you couldn't use these cells as is, but you might be
able to encode the protocol in an HTTP header or something.

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

Something like this might work too, so long as it's in an HTTP header
which a regular HTTPS server would simply reject and ignore.

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

See the section at the end of Tor proposal 203
(https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/203-https-frontend.txt
) for more ideas on this.

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

If every ill-formed request is handled by the web server, an attacker
could probe for Tor by sending a well-formed but incorrect AUTHORIZE
cell.  Or by sending an incomplete authorize cell: we couldn't
rejected it until we see the whole thing, but a real web server would
reject it much sooner.

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

THis sounds like a questionable idea; we're trying to resist ISP-level
adversaries who can forge IP addresses.  Also, dynamic IP exists, so
you don't want to be whitelisting an IP long-term.

best wishes,
-- 
Nick
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev