On Sat, May 29, 2010 at 4:29 PM, Kobi Shmueli <kobi@dal.net> wrote:
My answer was that a user can't (guarantee that all servers are connected to each other via SSL nor can s/he guarantee another user didn't use telnet to connect to his "secured" IRC session).
Ah, Ok.. that makes more sense to me. A user cannot guarantee much at all. Maybe what "+S" should do, that would actually make a useful security enhancement, is to guarantee the conversation can only traverse SSL encrypted links between IRC servers. That is, if the mode is +S, and a user sends a PRIVMSG, to a channel, the IRC server will not forward that PRIVMSG to any directly IRC server that is not connected using SSL, even if that IRC server will normally see the message. Instead it will forward the message with text changed to <text removed due to insecure connection> This way if there is an insecure connection between IRC servers, somewhere, the users on the other side of the trust break will know, to change servers, in order to secure their connection. For User A to convince User B that User A's connection is secure, some out of band method is needed. Well, if there is any insecure or untrusted link between the two users, there exists a possibility for an adversary to hijack that link, and lie about the security of User A's connection. It would probably be beneficial to have an extension to the /WHOIS command that does two things: (a) Computes the server<-> server path to the user, and (b) Checks the 'user mode' If and only if all server<->server connections to the user are SSL encrypted, and the user's mode is +S, then present to the user issuing the /WHOIS that the user's IRC Protocol connection is secured -- -J