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

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

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

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 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:

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

I'm a bit confused. So these checks are not currently working? I would assume things would work exactly as Kobi mentions.