I beleive that we need some improvements for this particular channel mode that does not exist in the latest version of bahamut: 1) +S should be available only for channel opers connected through SSL (In a case of a new channel with one single chanoper). 2) +S should be available for use ONLY if ALL users in the channel are connected through SSL. 3) Invites should NOT over-ride +S and if for any reason someone non-ssl joins, S mode should be removed by the server. 4) No exceptions/overrides for /samode. (Perhaps only ulines should override it but at as far as i know ircservices at least "enforce" the mode and kicks out non-ssl users). In my opinion, these checks should be done before the mode set to ensure that a +S channel is a channel that only SSL users are actually there. We have to be sure that when i'm on a +S channel, the channel is actually secure. Because even if only one user in the channel is not connected with SSL, it breaks the whole porpuse of this mode -> the conversation in the channel is transmitted somewhere (to a non-ssl user) unencrypted. Thanks :)
Coca Cola wrote:
1) +S should be available only for channel opers connected through SSL (In a case of a new channel with one single chanoper).
I agree with that.
2) +S should be available for use ONLY if ALL users in the channel are connected through SSL.
How do you suggest we enforce that?
3) Invites should NOT over-ride +S and if for any reason someone non-ssl joins, S mode should be removed by the server.
I agree with the /invite part and I also think the +I list shouldn't bypass it either. As for the second part, I don't really see the point if servers will only allow SSL users to join.
4) No exceptions/overrides for /samode. (Perhaps only ulines should override it but at as far as i know ircservices at least "enforce" the mode and kicks out non-ssl users).
I disagree with that, /samode and /sajoin should be able to bypass these restrictions. -Kobi.
See Comments On 5/26/2010 5:15 PM, Kobi Shmueli wrote:
Coca Cola wrote:
1) +S should be available only for channel opers connected through SSL (In a case of a new channel with one single chanoper).
I agree with that. I don't get it. How did DALnet implement the +S channelmode? It sounds like they deviated from what everyone else to my knowledge does with this mode. We researched this heavily 5 or 6 years ago when we implemented it and.. back then there were not many SSL capable networks out there... less than a dozen for sure. To my knowledge, all that have implemented some form of SSL only user restriction have followed the same rules we followed. I think we may have gone just a bit further, but not by much. I need to look at it more in depth.... I am just very busy these days.
2) +S should be available for use ONLY if ALL users in the channel are connected through SSL.
How do you suggest we enforce that? Easily. No SSL no join.
3) Invites should NOT over-ride +S and if for any reason someone non-ssl joins, S mode should be removed by the server.
I agree with the /invite part and I also think the +I list shouldn't bypass it either. As for the second part, I don't really see the point if servers will only allow SSL users to join.
The whole point for some of us coding +S into Bahamut with SSL was to prevent anyone NOT using SSL from joining the channel. -Period- There are a certain subset of users that want it that way, for whatever reasons.. not for me to decide. [on Freequest] when we created these modes it was simple.... if your NOT using SSL you are -NOT- getting in. The only exception to this was being an oper or a service. We were early adopters of SSL and had to learn all of this the hard way. In short, I can't see what the point of having an SSL only channel mode (if this is what it is) that does not prevent non-SSL clients from joining. Hence the above question.... what did DALnet do differently from virtually everyone else?
4) No exceptions/overrides for /samode. (Perhaps only ulines should override it but at as far as i know ircservices at least "enforce" the mode and kicks out non-ssl users).
I disagree with that, /samode and /sajoin should be able to bypass these restrictions. We never prevented this either, and because we want services/opers to chase into +S channels as well. Like it or not users do incredibly dumb things and opers/admins have to gain entry to stop whatever crap users are doing that are a detriment to the network or -other- networks.... be it flooding, operating botnets, etc. Disallowing this gives botnet operators a free ride... I can pretty much say for certain that it won't happen on any network... or let me put it this way - any network that is managed with anyone that has common sense. I have seen some stuff in my many, many years out here.
But, this is DALnet.. and you guys do what you will :) On another note, thanks for finally putting SSL support in..... makes life easier when merging back :) Although it does appear I have to fix some things still. -Mark
-Kobi. _______________________________________________ DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
It seems like a really a bad idea to introduce any new modes that /INVITE cannot override, as it introduces new poorly-understood methods that can be used by a channel hijacker/taker-overer. What is the point of this +S mode, who would we expect to use it, how many users would actually want to use it immediately, and what would we expect to accomplish with it? Can you guarantee that all IRC servers perform SSL/TLS encryption of all traffic between servers, and no non-SSL-connected IRC server is capable of JOINing a user to the channel or effecting it in any manner so as to alter settings or receive traffic from the channel? Can you guarantee a user hasn't telnetted into a server and run an IRC client from it? It seems like end-to-end encryption is a guarantee we can never make even at an IRC protocol level (without considering the multitude of ways a session can seem to be encrypted but be totally insecure), so trying to imply "mode +S" should make an assertion like that, is like IRCD trying to make a false promise....
3) Invites should NOT over-ride +S and if for any reason someone non-ssl joins, S mode should be removed by the server. -- -J
Well James, The purpose of +S is to ensure all users in that channel (Channel that is +S) are connected via SSL. Each individual user, must be umode +S (SSL) in order to join. Thus, making sure ALL users are encrypted. 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. So, what he is wanting is a way to ensure that all users encrypted, so at no point (atleast no point of a users end), is the data non-encrypted. It is used on other networks, although, I can't recall which ones off hand. [ Irvine A. Eatmon ] [ prez - prez@dal.net ] [ rapport.ix.us.dal.net ] [ Global Operator - Services Administrator ] [ Web Team Member ]
It seems like a really a bad idea to introduce any new modes that /INVITE cannot override, as it introduces new poorly-understood methods that can be used by a channel hijacker/taker-overer.
What is the point of this +S mode, who would we expect to use it, how many users would actually want to use it immediately, and what would we expect to accomplish with it?
Can you guarantee that all IRC servers perform SSL/TLS encryption of all traffic between servers, and no non-SSL-connected IRC server is capable of JOINing a user to the channel or effecting it in any manner so as to alter settings or receive traffic from the channel?
Can you guarantee a user hasn't telnetted into a server and run an IRC client from it?
It seems like end-to-end encryption is a guarantee we can never make even at an IRC protocol level (without considering the multitude of ways a session can seem to be encrypted but be totally insecure), so trying to imply "mode +S" should make an assertion like that, is like IRCD trying to make a false promise....
3) Invites should NOT over-ride +S and if for any reason someone non-ssl joins, S mode should be removed by the server. -- -J
DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
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
James Hess wrote:
It seems like a really a bad idea to introduce any new modes that /INVITE cannot override, as it introduces new poorly-understood methods that can be used by a channel hijacker/taker-overer.
That was my concern when we added that cmode, I didn't want it to be used as a takeover tool.
Can you guarantee that all IRC servers perform SSL/TLS encryption of all traffic between servers, and no non-SSL-connected IRC server is capable of JOINing a user to the channel or effecting it in any manner so as to alter settings or receive traffic from the channel?
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 shouldn't consider a public channel secured anyway, way too many things can make it unsecure without them even knowing. Vin King wrote:
For 2, I suspect this mode should be modeled after the behavior of +O. I haven't played with +S much yet, is that how it currently behaves?
cmode +S currently behaves like other cmodes (such as +O), people can bypass it with /invite and the invites list (and while riding a netsplit). We have ways to really enforce a channel to be +O unlike +S, though. Bradley Claghorn wrote:
I'm a bit confused. So these checks are not currently working? I would assume things would work exactly as Kobi mentions.
Those checks were not implemented on DALnet (yet) due to the above reasons. With that said, we understand the concerns about it and we are considering other options to make sure it won't be used to takeover channels (such as having an mlock of -S by default). -Kobi.
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
James Hess wrote:
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
Let me clarify it for those who missed my point. I quoted:
Can you guarantee that all IRC servers perform SSL/TLS encryption of all traffic between servers, and no non-SSL-connected IRC server is capable of JOINing a user to the channel or effecting it in any manner so as to alter settings or receive traffic from the channel?
Can you guarantee a user hasn't telnetted into a server and run an IRC client from it?
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). -Kobi.
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
On Wed, May 26, 2010 at 6:25 PM, James Hess <mysidia@gmail.com> wrote:
It seems like a really a bad idea to introduce any new modes that /INVITE cannot override, as it introduces new poorly-understood methods that can be used by a channel hijacker/taker-overer.
What is the point of this +S mode, who would we expect to use it, how many users would actually want to use it immediately, and what would we expect to accomplish with it?
Can you guarantee that all IRC servers perform SSL/TLS encryption of all traffic between servers, and no non-SSL-connected IRC server is capable of JOINing a user to the channel or effecting it in any manner so as to alter settings or receive traffic from the channel?
Can you guarantee a user hasn't telnetted into a server and run an IRC client from it?
It seems like end-to-end encryption is a guarantee we can never make even at an IRC protocol level (without considering the multitude of ways a session can seem to be encrypted but be totally insecure), so trying to imply "mode +S" should make an assertion like that, is like IRCD trying to make a false promise....
IRC over SSL is rather pointless for most use cases. It's real benefits are few and far between. As you pointed out, the ircd simply cannot guarantee all traffic is encrypted and thus "secure." A lot of assumptions have to be made, for example, a.) servers are never compromised and do not log anything, b.) the server has a valid certificate with fingerprint located somewhere out of band where people can verify its authenticity, c.) servers ONLY support encrypted connections, period, d.) clients are never compromised and don't log anything (e.g., MITM attacks), etc. An easy example of IRC over SSL being "broken", most web irc clients allow SSL connections to IRC servers over HTTP. The ircd has no idea traffic is really going over unencrypted HTTP and thus would allow you to join an SSL-only channel. BNCs are another example. It's a false sense of security for most, which some would argue is worse than not having SSL at all.
On Sat, May 29, 2010 at 7:26 PM, Jason Hill <secrtagnt@gmail.com> wrote:
IRC over SSL is rather pointless for most use cases. It's real benefits are few and far between.
I disagree. If you can trust your irc server/network, ssl provides benefits: I know that content in transit between me and my server cannot be decrypted. That was the _ONLY_ goal of ssl.
An easy example of IRC over SSL being "broken", most web irc clients allow SSL connections to IRC servers over HTTP. The ircd has no idea traffic is really going over unencrypted HTTP and thus would allow you to join an SSL-only channel. BNCs are another example.
This argument is bull. The same could be said of every single other ssl mechanism out there. Bahamut is not trying to be silk. If you want full, end-to-end encrypted chat that addresses all of your concerns, use silk. And for the extra paranoid, run it over tor. We implemented SSL for two reasons: feature parity with other ircds out there, and the client<->server tcpdump snooping prevention. I'll address some of the usability and implementation quirks that have been mentioned in this thread, but the direction this conversation is going is pointless. -epiphani
On Sat, May 29, 2010 at 7:22 PM, Aaron Wiebe <epiphani@gmail.com> wrote: > On Sat, May 29, 2010 at 7:26 PM, Jason Hill <secrtagnt@gmail.com> wrote:>>
I disagree. If you can trust your irc server/network, ssl provides benefits: I know that content in transit between me and my server cannot be decrypted. That was the _ONLY_ goal of ssl. Yes, there is some value to SSL encrypted client connections.
An easy example of IRC over SSL being "broken", most web irc clients allow SSL connections to IRC servers over HTTP. The ircd has no idea [snip] This goes back to there being no security validations or standards for IRC clients. However, if you will trust some random web site with your IRC connection, do not be surprised if the implementation is flawwed or backdoored.
In addition, an untrusted party could have injected code into or tampered with the web site, by exploiting the webmaster's weak FTP password (for example). It's ok for IRCD to provide an option to use SSL, even if some IRC clients are flawwed.
This argument is bull. The same could be said of every single other ssl mechanism out there.
Tthe same could not be said of every single SSL mechanism... this is a unique situation. Most SSL implementation scenarios involve a communication that is only between two directly connected parties; a client application and a server, the conversation doesn't go any further. Securing that and representing things accurately is much easier in that scenario, than where you have a semi-trusted intermediary attempting to enable multiple parties to communicate. The closest similar situation to this is e-mail. You can connect to your SMTP server using SSL or TLS to send an e-mail message. Just like you can connect using SSL to a supporting IRC server. However, the fact that you send an e-mail message over SSL or TLS doesn't mean the recipient will get the message, without it ever passing over plaintext. There is no box you can check on your mail client "Do not allow recipient to read this message using non-SSL POP3" Basically the same reason I suggest there should be no box you can check in your IRC client's channel modes list " [ ] +S - Do not allow user to join channel if using non-SSL" -- -Mysid
On Sat, May 29, 2010 at 7:22 PM, Aaron Wiebe <epiphani@gmail.com> wrote:
I disagree. If you can trust your irc server/network, ssl provides benefits: I know that content in transit between me and my server cannot be decrypted. That was the _ONLY_ goal of ssl.
As I said, it's real benefits are few and far between -- not that they don't exist.
This argument is bull. The same could be said of every single other ssl mechanism out there.
Bahamut is not trying to be silk. If you want full, end-to-end encrypted chat that addresses all of your concerns, use silk. And for the extra paranoid, run it over tor. We implemented SSL for two reasons: feature parity with other ircds out there, and the client<->server tcpdump snooping prevention. I'll address some of the usability and implementation quirks that have been mentioned in this thread, but the direction this conversation is going is pointless.
-epiphani
Other implementations suffer from the same problems, but the incentives are different. That doesn't make the example I gave any less valid. BTW, I was specifically referring to services such as mibbit (qwebirc mostly being an exception). Yes, that example doesn't really hold true for java applets, and I agree with you there. I'm not by any means advocating for true end-to-end encryption. I don't think that is feasible for IRC, and frankly, not needed. I understand why such functionality was implemented in bahamut, and, ironically enough, I just finished up a patch for implementing SSL in ircu .12. There is some value in SSL-enabled connections, I don't dispute that. I just don't feel the value it does provide is that significant -- obviously others disagree, and that's fine. I was merely pointing out that the ircd cannot ensure the security of any conversations taking place in a channel, and simply should not try -- which was the direction the conversation was heading in when I replied. That doesn't make cmode +S pointless, but users should understand its limitations. -Jason
And one other thing... On Sat, May 29, 2010 at 7:26 PM, Jason Hill <secrtagnt@gmail.com> wrote:
An easy example of IRC over SSL being "broken", most web irc clients allow SSL connections to IRC servers over HTTP. The ircd has no idea traffic is really going over unencrypted HTTP and thus would allow you to join an SSL-only channel. BNCs are another example.
Most of those web irc clients are java applets. They connect from your machine, not via the web server. There is no unencrypted http relaying of content there. -Aaron
I'm a bit confused. So these checks are not currently working? I would assume things would work exactly as Kobi mentions. -- Bradley Claghorn Visigoth @ IRC punch.dal.net outpost On Thu, 27 May 2010, Kobi Shmueli wrote:
Coca Cola wrote:
1) +S should be available only for channel opers connected through SSL (In a case of a new channel with one single chanoper).
I agree with that.
2) +S should be available for use ONLY if ALL users in the channel are connected through SSL.
How do you suggest we enforce that?
3) Invites should NOT over-ride +S and if for any reason someone non-ssl joins, S mode should be removed by the server.
I agree with the /invite part and I also think the +I list shouldn't bypass it either. As for the second part, I don't really see the point if servers will only allow SSL users to join.
4) No exceptions/overrides for /samode. (Perhaps only ulines should override it but at as far as i know ircservices at least "enforce" the mode and kicks out non-ssl users).
I disagree with that, /samode and /sajoin should be able to bypass these restrictions.
-Kobi. _______________________________________________ DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
participants (9)
-
Aaron Wiebe -
Bradley Claghorn -
Coca Cola -
Irvine A. Eatmon - prez -
James Hess -
Jason Hill -
Kobi Shmueli -
Mark Rutherford -
Vin King