Make Servers Stop Rejecting Requests

[dnwiebe]

Dan made a mistake.

Before GH-716, we had a stream-key generation method that created stream keys by hashing our public key together with the server host name. This was adjudged insecure, because an exit Node would know the server name, and it had a neighborhood database full of public keys, and it could traverse its database and use each public key in turn to hash with the server name until it found a hash that matched the stream key it had been given; then it would know which originating Node it was serving for.

Dan noticed this vulnerability, but suggested the wrong fix to it. The fix suggested was to generate stream keys without any dependence on public key, so that the exit Node couldn't reverse-engineer it. As a matter of fact, we are now generating stream keys completely at random, with no dependence on anything at all. That worked to eliminate the exit-Node attack, but it caused another problem.

Whenever the browser requests a connection to a server through the MASQ Network, the originating Node computes a stream key for that connection request and compares it to all the stream keys it already knows; if it doesn't already know the newly-computed stream key, it requests the Neighborhood to generate a new route for the stream.

Before GH-716, every browser request to a particular host name would generate the same stream key as every other browser request to that host name, because the stream key was hashed from the host name and public key. That means that all traffic to that host would pass through the same route through the MASQ network.

However, after GH-716, each browser connection request generates its own unique stream key, resulting in a new routing request to the Neighborhood; the Neighborhood may return a route using a different exit Node, which means that the server will get identical session information from two different IP addresses. This is suspicious behavior, which may well cause an attentive server to reject the second request (and perhaps cut off the first connection as well, if it's sufficiently paranoid).

What Dan should have suggested is that the hashing operation stay the same, since it provides convenient stream-key collisions on the originating side that direct connection requests for the same server down the same route to the same exit Node; but the the material being hashed should be modified so that it doesn't entirely consist of things known by the exit Node. For example, instead of hashing in our public key, we could hash in something else: random salt, perhaps, that's generated at bootup time and stored in the Proxy Server.