On Tue, Oct 13, 2009 at 8:33 PM, Vin King <vin.king@gmail.com> wrote:
As I said in the email you quoted, SSL is actually becoming a concern, as there is more room for monitoring with open networks these days. Client to server communications should have an expectation of privacy. That being said, when the conversation is started with the idea that each server should hash the address independently, then channel operators would have no protection from server to server movements by a rogue client. Nick based hostmasks allow for a collection of hostmasks to be generated.
The actual security provided by client-side SSL is debatable. Trust is not transitive, and for client-side SSL to truly work a lot of assumptions have to be made (e.g. clients are not on compromised machines with logging turned off, servers are not on compromised machines and don't log anything, etc.); however, this is another discussion in itself. That said, independent hashing of the address can work reliably, depending on the algorithm being used; however, it would also be rather trivial for the user's server to generate the hash during the registration process and propagate it across the network to other servers (e.g. by using NICK or by implementing something like ENCAP <sub-command>). I also agree that nickname-based hostmasks won't work reliably on DALnet, given how insanely easy it is to register a nickname.
The potential from abuse by a vhost is mitigated by wildcarding the ip address, which can't be done with hostmasks.
Additionally, with each hostmask now being independent, wildcard bans on ISPs become ineffective, and the current limitations on ban list lengths become a major shortfall.
Providing the capability without proper planning into all the affected systems will easily create room for abuse, especially if the system isn't properly tested for abuse potential.
Specific examples of how hard it is for your average channel operator to keep a determined attacker out of a channel when the IRCD provides the attacker with the ability to change their hostmask can be seen on any network that does provide the address. I know I myself have abused the capabilities of other networks easy enough, so it's not impossible.
I personally don't see how hostmasking provides any end user security, as the vast majority of the network users are not dealing with attacks against themselves or their connections, and since the vast majority of attacks on the network are through query anyways with OMG DO THIS FOR OPS //decode
Ban evasions will be possible with or without hostmasking; however, a lot of what you mentioned can be mitigated by the fact that a server will know both the real and masked host for a user. This makes it possible for ban list entries (and silence lists, etc) to be easily matched against a user, regardless of whether a user has enabled/disabled hostmasking and whether the ban is against the user's real or masked host. For example, a ban against *!*@*.aol.com should work even if the user is umode +H and their mask is generated based on their IP address (due to the server being unable to perform a reverse lookup).
It's good to hear that SSL is coming, as more and more of our users these days are using untrusted public connections.
-SecretAgent