search

charybdis-ircd / charybdis

Scalable IRCv3.2 server for large, community-oriented networks
GNU General Public License v2.0
230 stars 102 forks source link

Host cloaking could be better #4

Closed dgl closed 12 years ago

dgl commented 12 years ago

The host cloaking isn't that great, at least for short strings. I can't attach code here, but some code and findings are here: http://pastie.org/4743103

dwfreed commented 12 years ago

It's not intended to be perfect, and it really can't be. If you care that much, use vhosts in a services system (such as Atheme).

dgl commented 12 years ago

Fair enough, but I was surprised just how weak it was, it would be nice to mention that in the docs at least.

dwfreed commented 12 years ago

You're also just brute-forcing it. For a 6 character subdomain, there's only 26^6, or 308,915,776, possibilities, which is very easily brute-forced by a modern computer, especially since the FNV hash is insanely fast. No matter what, you can't win, unless you make the cloaked subdomain longer, which is not the intention of the cloaking module.

dgl commented 12 years ago

Sure, but something like a shared secret used in a cryptographically secure hash would make things considerably harder.

alyx commented 12 years ago

Granted, if someone was wanting to find an IP, and they knew enough to know how to get around charybdis' host cloaking, they'd probably be smart enough to know other ways of obtaining an IP anyway...

kaniini commented 12 years ago

We decided a long time ago that we really did not want to carry cryptographic code in the IRCd or create a hard dependency on openssl. It is possible to supply a different cloaking module if you would like to carry crypto code in your IRCd -- SorceryNet does this for example in their SorIRCd stuff.

It is a known fact that the cloaking module is not very effective, but I do not believe that using a cryptographically secure hash for the value used to permute the characters in the hostname will really provide any improvement to the fact that hosts can be bruteforced. I would say that the fact that it takes 16 seconds to bruteforce 'foobar.foobar' in your example shows that it is at least better than SHA1 would perform here, and SHA256/SHA512/Whirlpool/Tiger are too expensive.