Author Topic: UltimateIRCd +S behaviour  (Read 12310 times)

Offline ShadowMaster

  • Chief Codemonkey
  • Administrator
  • ********
  • Posts: 3136
    • View Profile
    • http://www.shadow-realm.org/
UltimateIRCd +S behaviour
« on: May 02, 2004, 10:45:03 am »
At current, UltimateIRCd will allow Channel Operators to invite non secure clients into +S channels. Upon doing so, a notice will be sent to ALL clients in the channel that this has occured.

This behaviour have been questioned, and i would like some community input on it before i decide just what to do about it.
Search before posting - No support by PM or IM

Offline Plasma

  • Needs to get out more
  • ****
  • Posts: 106
    • View Profile
UltimateIRCd +S behaviour
« Reply #1 on: May 02, 2004, 11:19:07 am »
Of course not!

+S means its a secure/encrypted convo between all parties, you dont want an exception to this rule.

Offline cg

  • Outstanding community member
  • **
  • Posts: 27
    • View Profile
    • http://tigerdriver.de
UltimateIRCd +S behaviour
« Reply #2 on: May 02, 2004, 02:23:43 pm »
I agree with Plasma but i don´t really now what kind of encryption the +S is. If +S is ssl only it would be a security risk if a person without ssl can join the channel. Even IRC Operators shouldn´t be able to join in such a channel without ssl. But i must mention that i currently don´t know for sure what +S is or should be.

Greetings
Christian 'cg' :badword:er
RTFM & RTFRFC! :)

Offline Quinn

  • Codemonkey
  • ****
  • Posts: 184
    • View Profile
UltimateIRCd +S behaviour
« Reply #3 on: May 02, 2004, 08:04:00 pm »
If a chanop wants to invite a non SSL client into an +S channel, make it -S. +S exists for a reason - to provide a channel where only SSL encrypted clients can talk, if you allow non-SSL clients into this channel, then you may as well not have +S to start with.

Just my view (even though I, myself do not have an SSL capable client).
Quinn 8)

Offline Preacher

  • Needs to get out more
  • ****
  • Posts: 136
    • View Profile
    • http://www.knightirc.net
UltimateIRCd +S behaviour
« Reply #4 on: May 02, 2004, 11:25:58 pm »
I agree with quinn,

though It might be an idea if an ircop could fjoin even if the ircop does not have an ssl client...

shalom

Preacher 8)
irc.knightirc.net

http://www.knightdomains.biz, for all your domian and server needs

Offline Quinn

  • Codemonkey
  • ****
  • Posts: 184
    • View Profile
UltimateIRCd +S behaviour
« Reply #5 on: May 02, 2004, 11:51:14 pm »
I forgot all about IRCops, perhaps allow them FJOIN or make it a config setting (dare I say an extra flag?) or at least an extra notice - something like IRCOP <name> is forcing JOIN to SSL channel <name>... it doesn't even have to be an extra flag, but a 'louder' notice to say that an IRCop is forcing a join to an SSL chan, not just a normal chan...

Thoughts?
Quinn 8)

Offline Plasma

  • Needs to get out more
  • ****
  • Posts: 106
    • View Profile
UltimateIRCd +S behaviour
« Reply #6 on: May 03, 2004, 01:38:19 am »
Quote from: "Quinn"
If a chanop wants to invite a non SSL client into an +S channel, make it -S. +S exists for a reason - to provide a channel where only SSL encrypted clients can talk, if you allow non-SSL clients into this channel, then you may as well not have +S to start with.

Just my view (even though I, myself do not have an SSL capable client).


That brings something else up - can you set +S to a channel with non-SSL clients in it?

Offline sidewinder

  • Always here
  • *****
  • Posts: 252
    • View Profile
UltimateIRCd +S behaviour
« Reply #7 on: May 04, 2004, 08:16:57 pm »
Quote
That brings something else up - can you set +S to a channel with non-SSL clients in it?


I know for a fact that you can't set +S without being on a SSL connection yourself...haven't tried this one out..
sidewinder
Network Admin
irc.wiredpatrol.org

http://www.wiredpatrol.org

Offline ShadowMaster

  • Chief Codemonkey
  • Administrator
  • ********
  • Posts: 3136
    • View Profile
    • http://www.shadow-realm.org/
UltimateIRCd +S behaviour
« Reply #8 on: May 04, 2004, 08:56:29 pm »
You can set +S on a channel where non secure users are already inside.
I do not see adding a check for this as realistic as it could easilly be used as a DoS tool against the server.

Connect a few hundred clones to a channel, start flooding +S/-S modechanges and the IRCd would have to check the flags for every single client on every single modechange.

Some things are just better left in the hands of humans, regardless of how stupid they might be =P
Search before posting - No support by PM or IM

Offline Preacher

  • Needs to get out more
  • ****
  • Posts: 136
    • View Profile
    • http://www.knightirc.net
UltimateIRCd +S behaviour
« Reply #9 on: May 04, 2004, 09:45:33 pm »
very true 8)
irc.knightirc.net

http://www.knightdomains.biz, for all your domian and server needs

Offline Quinn

  • Codemonkey
  • ****
  • Posts: 184
    • View Profile
UltimateIRCd +S behaviour
« Reply #10 on: May 04, 2004, 11:44:23 pm »
Unfortunately, even in this day and age, that is true, albeit somewhat scary.

While I can see where the DoS stuff is coming from, what about this?
Channel is NOT +S :
Chanop sets +S - IRCd runs a quick check over who's in the chan, if they are NOT +S (SSL), then it removes them forcibly from the channel and prevents any non SSL joins, even through invite.

However, setting +S/-S plenty will cause the IRCd to have a small headfit as it checks each client over and over, only way to prevent that is to limit just how quickly you can perform a MODE change (such as +S), however then we get into a whole area of debate and general viper-nest stuff... May just be quicker (and easier) for us to leave it as is, at least as it is currently going +S/-S cannot DoS the server, which is more important IMO than the contents of a channel.

However, I just like to give options, even if they ARE fraught with pain and suffering... much like any other day at work really :)
Quinn 8)

Offline ShadowMaster

  • Chief Codemonkey
  • Administrator
  • ********
  • Posts: 3136
    • View Profile
    • http://www.shadow-realm.org/
UltimateIRCd +S behaviour
« Reply #11 on: May 05, 2004, 12:36:27 am »
Dont mind me. It was a thought not carried trough to the end.
Quinn is of course right. For some odd reason i was sitting thinking that nothing would be done about the clients *grin*

See... dont post when tired.
Search before posting - No support by PM or IM

Offline Quinn

  • Codemonkey
  • ****
  • Posts: 184
    • View Profile
UltimateIRCd +S behaviour
« Reply #12 on: May 05, 2004, 12:58:34 am »
Quote
For some odd reason i was sitting thinking that nothing would be done about the clients *grin*


What do you mean here SM? Am a little unsure as to whether that's sarcasm or something else I should have picked up on :P
Quinn 8)

Offline BarkerJr

  • Here a lot
  • ***
  • Posts: 97
    • View Profile
    • Hollimyer IRC Network
UltimateIRCd +S behaviour
« Reply #13 on: August 23, 2005, 01:35:57 am »
I think /invite should override every channel mode there is.  If the operator wants to make an exception to any rule, he should be able to do so.

Offline erich

  • Needs to get out more
  • ****
  • Posts: 132
    • View Profile
UltimateIRCd +S behaviour
« Reply #14 on: August 23, 2005, 10:29:59 am »
Quote from: "BarkerJr"
I think /invite should override every channel mode there is.  If the operator wants to make an exception to any rule, he should be able to do so.


nonono mate.
Thats not good.

Let me give you an example. You have a bot sitting in a channel which is doing invite for you. In this case "SITE INVITE <nick>"
Now... what would happen if you type a wrong nick or don't have that nick on the network where the bot is....
Another user might get the invitation and end up in a invite only channel. This isn't very nice.  The way that you can prevent this, is by adding a key on the channel aswell. And the key can't be overruled by invitation even. So.... i can't agree on your stating.


Note: I had to mod the IRCd to make this work, as the default doesn't which is a fault if you ask me.
Network Founder @ After-All.org
http://www.After-All.org

 

anything