Forums Feature Suggestions Custom CTCP VERSION Reply

Addressing each counterpoint..

* Just because some software is the newest, latest, etc, does not make it bug/exploit-proof. Quite the contrary, many "hackers" seem to focus on the latest and newest because they can find new bugs to exploit that are not already fixed, and may take awhile before an updated and fixed version becomes available. It only takes one bad bug to be found and posted on some "hacker" site before the droves jump on the bandwagon to exploit it before it gets too old to be useful anymore. (Kind of the same logic that was presented; old clients need to be updated to remain useful.. Same for "hacks" and exploits. It's a constant game of cat-and-mouse.)

Edit: Besides, you also mentioned whois to get the IP.. You're actually reinforcing what I said: A whois and IP does not tell them *anything* about what computer or software is at that location, no more than "1234 Main street" tells you if it's a vacant lot, or the US Gov't Gold Reserve. But you can be sure the Gold Reserve would get a lot more attention if it had flashing neon signs advertising it's presence..

* Networks that do version checks will always have that problem, regardless. This is especially true when someone wants to write their own client from scratch. Or as others have suggested, ignore version checks, or use some other hack to bypass version replies, etc. How will a network respond any different to those situations? And most "bad" clients fake a reply to appear to be a legitimate client, anyhow. Consider eggdrop bots for example; There's many TCL scripts which make eggdrop bots appear to be regular mIRC clients. (I don't want to get into a network policy debate on the mIRC forum, but really, there's better and more reliable methods to validate clients, anyhow. You wouldn't leave your keys in the ignition of your car just to prove you are the owner because the key fits, would you? I hope not.. but it illustrates my point, the methods used are going about it the wrong way.)

* As far as the comment towards mail/web browsers.. Much the same applies, for many of the same reasons. They certainly can be custom configured (My FireFox presents itself as MSIE, for example), and I don't know many mailservers that challenge which mail client and version is being used, only that it properly authenticate that it has proper access to the server, such as a user account. The idea that a mailserver accept a connection merely because the client is Outlook Express seems pretty flaky to me. Likewise, Apache HTTPd can be configured to identify itself as nothing, just "Apache", the short version, the full version, etc. In any case, the legitimate clients/servers rarely need to fully identify their brand/name/version/etc., because they use other means to authenticate. While the malicious/bad users, spammers, etc., do everything in their power to appear to be a fully legitimate client/server in hopes that poorly designed security measures will let them right in (again, think if a mailserver gave you full access if all you had to do was claim to be OE.. You think spam is a problem now? heh..)

So this and the previous two points not only carry little weight, they are counter-intuitive; Networks which realize versioning alone won't solve the problem will find more reliable methods, making it more difficult for malicious/bad users to get in. While those who believe it protects them will just have more bad clients lurking under the guise of legitimate clients, which will be even harder to detect. (I won't even get into the ethical debate of "We hate Khaled at so-n-so network, so we'll ban you if your version is mIRC" type policy controls. Just be thankful that hasn't happened.. yet.)

* Turning off or ignoring CTCP's isn't really a solution, either. First off, those are all-or-nothing options, and much akin to "just script it!" Second, I can think of many ways around mIRC's version replies, and do so without even violating the license (in spirit/intent, I don't think it specifically forbids blocking version replies.. ?) But why do all that for something that could easily (in theory) be put right in the client?

* Reporting to the ops/irc-ops is also not really a solution. First, there are many legitimate reasons to version check. I would never assume a version check IS a prelude to an attack, only be more wary and on the lookout for one. Second, if it is an attack, it is possible it will happen too fast for me to report it, and/or the ops to respond before half the channel gets wiped out. Third, what if the ops really don't care? This may not be good channel policy, and I would suggest finding a better channel.. But it still happens. Lastly, if we could always get others in a group to cooperate without fuss, there would be little need for half the features already present in mIRC, or any IRC client. (Ever try telling the ops to use alphabetic nicknames and join the channel in a proper, organized manner, so they appear at the top of the list, while voices and regs use nicks further on down the alphabet just to make mIRC show a neat list? Try it. They'll laugh at you.)

Good thoughts and comments by all.. just they either fall outside the scope/purpose of the suggestion, or have problems/issues of their own. (But ultimately, it's up to Khaled to decide ;-))