On Sat, May 29, 2010 at 3:30 PM, Kobi Shmueli <kobi@dal.net> wrote:
Can you guarantee a user hasn't telnetted into a server and run an IRC client from it? A user can't, that's why I didn't think it would be a big deal. One
Eh? Well, of course a user can. There are thousands of hosting providers IRC users use for that. It is particularly common in a university computer lab or net cafe for a user to connect to various systems using telnet. Shell accounts, VPS, and BNCs that support installing a client and connecting to IRC using SSL are easy to find, inexpensive, and frequently used by IRC users. They may not be allowed to install software, so they use a standard telnet client to access their own software remotely. There are many ways a user may find an old server they can run an IRC client from. Using telnet instead of ssh to access their server may be a novice mistake, but that never stopped anyone from making it. (They are usually only stopped if their provider turned off or warned them not to use telnet)
shouldn't consider a public channel secured anyway, way too many things > can make it unsecure without them even knowing.
Well, I agree... that is the point I am actually trying to express here. And the limitation I see with +S that makes it all but useless... +S should not be utilized by a user to conduct an e-commerce transaction on IRC, or share credit card / other financial details. But I think if the description of the mode is "Require all users to use SSL", this mode may be popularly equated to 'secure channel', and users might misunderstand this to be safe. Even with +S, we cannot ensure the security of multi-party conversations. All it takes is one user following insecure practices, having a bit of malware on their system, or logging and misplacing their log / leaking the log. There are no real standards, certifications, or established security best practices for IRC clients that support SSL. Such as requiring all logs of a secure conversation to be encrypted or not retained, blocking script access messages sent into secured conversations, etc. There are no FIPS140-2 validations for any IRC Clients I know of.. like there are web browsers and web servers. I would say extreme caution is warranted here, in terms of what security capabilities IRCD tries to provide for conversations, and how those capabilities are described to users. -- -J