hiding the real backend server address(#107)

[onestraw]

refer #107 for details

[onestraw]

Could you review the PR for #107 @juliens @emilevauge

[onestraw]

@klizhentas @archisgore any suggestions?

[archisgore]

If security is your goal, hashing is a bad idea. First of all no matter how strong the hash (and MD5 has been broken a lot), the cardinality of an IP address is only 4 bytes (32 bits) that means only about 4 billion combinations. MD5 generates an output that's 128-bits wide. Meaning nearly every IP will map to one and only one hashed value, making dictionaries even more trivial.

This problem gets much worse because MOST server IPs behind vulcan will be Private addresses, totaling about 17,891,328 (https://en.wikipedia.org/wiki/Private_network#Private_IPv4_address_spaces)

Since vulcan is open source, this will be broken trivially.

You need an irreversible transform (or a computationally difficult one to reverse.)

I don't mean to propose a solution here, but here are some thoughts:
My first pick would be a cryptographically secure random number. It would be arbitrary. This is difficult to do in a distributed system like vulcan (without writing back to etcd.) If this could be done, it would be completely unguessable and irreversible.

The other is to salt the hash with some shared random number. Only instances connected to that etcd cluster will have access to the salt value. An attacker would not.

An easy way to salt+hash is to use shared symmetric key. Then encrypt each server's name using this key. Even if the attacker has 17 million or so addresses, they would need to guess one of a bunch of key possibilities (depending on key length).

[archisgore]

Oh wait, I forgot, this isn't vulcan, but Oxy. Why not externalize the hash function? When instantiating NewStickySession() it can be passed an interface "Obfuscator"

type Obfuscator interface {
    Obfuscate(string) string
    Normalize(string) string
}

Implementors who know how to share data across instances can use random numbers. Other implementors might use salting. While others might be okay with hashing. At least at instantiation, it forces the implementor to make a decision and they know what they're getting into.