Hi: I've discovered that the GFW normally doesn't block https protocols. We can use a https front tier to distribute connections to actual bridges. The front tier encrypts an internal address identifier with its private key (no matching public key or public algorithm) and returns to user the encrypted identifier, part of which also includes the user's chosen password. Then when submitting requests, the user encrypt again with his password the items such as his timestamp, broswer headers. The request line to https server is no different from an ordinary one and include both the user encrypted item and front tier encrypted item. After the connection is established, data is relayed inside https between bridge and user.
wait... what? What is this front tier? Why would we want to use cryptographic protocols for bridges that violate the end to end principal? On Mon, Oct 26, 2015 at 8:44 AM, Da Feng <sunspiderx@gmail.com> wrote:
Hi: I've discovered that the GFW normally doesn't block https protocols. We can use a https front tier to distribute connections to actual bridges. The front tier encrypts an internal address identifier with its private key (no matching public key or public algorithm) and returns to user the encrypted identifier, part of which also includes the user's chosen password. Then when submitting requests, the user encrypt again with his password the items such as his timestamp, broswer headers. The request line to https server is no different from an ordinary one and include both the user encrypted item and front tier encrypted item. After the connection is established, data is relayed inside https between bridge and user. _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Mon, 26 Oct 2015 15:44:59 +0800 Da Feng <sunspiderx@gmail.com> wrote:
Hi: I've discovered that the GFW normally doesn't block https protocols. We can use a https front tier to distribute connections to actual bridges. The front tier encrypts an internal address identifier with its private key (no matching public key or public algorithm) and returns to user the encrypted identifier, part of which also includes the user's chosen password. Then when submitting requests, the user encrypt again with his password the items such as his timestamp, broswer headers. The request line to https server is no different from an ordinary one and include both the user encrypted item and front tier encrypted item. After the connection is established, data is relayed inside https between bridge and user.
So... meek (https://trac.torproject.org/projects/tor/wiki/doc/meek), the basis of which will probably also be used for bridge distribution purposes in the future. Regards, -- Yawning Angel
On Mon, Oct 26, 2015 at 03:44:59PM +0800, Da Feng wrote:
Hi: I've discovered that the GFW normally doesn't block https protocols. We can use a https front tier to distribute connections to actual bridges.
This is a good idea. HTTPS is a good cover protocol.
The front tier encrypts an internal address identifier with its private key (no matching public key or public algorithm) and returns to user the encrypted identifier, part of which also includes the user's chosen password. Then when submitting requests, the user encrypt again with his password the items such as his timestamp, broswer headers.
If I understand this correctly, this is a defense against active probing. You are saying that every HTTPS bridge has a password, and the client must provide the correct password in order to use the bridge. (Like ScrambleSuit or obfs4.) If the GFW tries to connect to the bridge, it does not know the password, and therefore it cannot use the bridge.
The request line to https server is no different from an ordinary one and include both the user encrypted item and front tier encrypted item. After the connection is established, data is relayed inside https between bridge and user.
You can already do something like this, except for the active probing defense, using a PHP script and Tor Browser. First install this file on an HTTP server: https://gitweb.torproject.org/pluggable-transports/meek.git/tree/php/index.p... (Let's say it is installed at https://example.com/meek/index.php.) Then, in the Tor Browser bridge configuration, enter the bridge line: meek 0.0.2.0:1 url=https://example.com/meek/index.php See "What to do if meek gets blocked" for some more options: https://lists.torproject.org/pipermail/tor-talk/2015-January/036410.html
participants (4)
-
Da Feng -
David Fifield -
David Stainton -
Yawning Angel