On Wed, May 26, 2010 at 11:50 PM, Irvine A. Eatmon - prez <prez@dal.net> wrote:
Each individual user, must be umode +S (SSL) in order to join. Thus, making sure ALL users are encrypted.
That's the concern I see... with that purpose attached to it... it suggests the mode is a user visible indication of security, basically like a padlock and 'trust seal' that can be seen on an e-commerce web site, when a channel is +S. The problem is that IRCD cannot verify any member user's connection is really encrypted or see beyond the SSL status of a user's TCP connection to the IRC server. The connection between the user's terminal and their IRC client is commonly separate and can be unencrypted, for example a telnet connection to an IRC BNC, a telnet connection to a shell account, or a Windows VNC or RDP session. The IRC server will never know about that and will set them mode +S anyways, based on the SSL IRC link. So a highly visible +S has a big risk of creating a false impression of high security in various cases.. Leading the user to falsely believe they are secure. Well, that's not so bad... the problem is representing to other people in the channel who have no way to know about that one user's setup, to be implied that that the entire channel is secure at the ends, when IRCD cannot feasibly certify this. Also the server doesn't directly know whether each client validated the server's SSL cert, to ensure it was not forged, and would reject a MITM attack, or the user would simply click OK / ignore warning and connect anyway, to even a fake certificate, in case of a man-in-the-middle. I do not suggest that DALnet attempt to assure users that they can use a channel mode to make sure of end-to-end encryption. If information of sensitivity that requires a guarantee of end-to-end hard encryption needs to be sent, there are more suitable methods, such as PGP e-mail, with keys stored on hardware crypto devices. Or the members can do the manual work required to ensure end-to-end security.
As, if even just one user in a channel is not connected via SSL, then the purpose of SSL becomes fairly moot to begin with. Since, all of your data sent (even if you are connected via SSL) is plain text to that persons machine, thus making it non-encrypted at that point anyways.
SSL does not become quite moot in that case, it still reduces the overall number of places where a message can potentially be intercepted. Every hop that a message is transmitted encrypted over, is one hop where the message could not have been easily captured or misappropriated It still protects passwords and such transmitted to services over private message, over certain hops, which is (probably) the primary benefit of SSL encrypted IRC sessions. SSL user connections are most beneficial for small private channels, and one-on-one conversations, where the perception of increased confidentiality should benefit users, and be an accurate perception in most cases. The more users involved in a conversation, the more potential places for a leak, security issue, or user error. -- -J