Re: [Standards] XEP-0045 1.25rc7
On 10/24/11 3:13 AM, Mike Wacker wrote: > On 10/3/2011 8:05 PM, Mike Wacker wrote: >> I've checked a new provisional version of XEP-0045 into git... >> >> Latest diff: >> >> http://xmpp.org/extensions/diff/api/xep/0045/diff/1.25rc6/vs/1.25rc7 >> >> Diff from 1.24: >> >> http://xmpp.org/extensions/diff/api/xep/0045/diff/1.24/vs/1.25rc7 >> >> Rendered version: >> >> http://xmpp.org/extensions/tmp/xep-0045-1.25.html >> >> Continued feedback would be appreciated. >> >> /psa >> >> > > It may help to include the full end-to-end flow for discovering > component support for MUC. Unlike other features, MUC often must live on > a separate domainpart (chat.shakespeare.lit) than the one an entity > negotiates a stream with (shakespeare.lit); otherwise it would be > impossible to tell if ha...@shakespeare.lit/pda is a full jid or a room > jid. Not true. The subdomain convention is nice but not necessary. > In 6.1, the ha...@shakespeare.lit/pda send a disco#info request to > chat.shakespeare.lit, but it never says how hag66 determined that > chat.shakespeare.lit exists in the first place. I'm not sure why we never included a section about that. Added. /psa
Re: [Standards] XEP-0045 1.25rc7
On 10/6/11 4:36 AM, Alexander Holler wrote: > Am 05.10.2011 21:56, schrieb Mike Wacker: >> On 10/4/2011 11:15 AM, Alexander Holler wrote: If the server never times out a room that is created but not configured and unlocked, then an easy DOS vector is to flood the server with room creation requests but never configure any of the rooms. Since these unconfigured rooms never time out, these creation requests will eventually starve the server of resources. Throttling won't work here, as it will slow but not stop the eventual starvation. Two mitigations would be to either time-out unconfigured rooms or put a cap on the number of unconfigured rooms a single user can create. You could also have a max cap of total rooms for all users, but that also has DOS implications because even if malicious users can't DOS the server, they can DOS other users trying to create rooms if they can hit the server cap. >>> >>> Whats the difference between unconfigured and configured rooms? >>> >>> It's as easy to DOS a server with configured rooms as with >>> unconfigured rooms and it will cost a malicious client almost nothing >>> to configure a room along with the creation. >>> >>> Regards, >>> >>> Alexander >> Good call, Alexander, my initial line of inquiry began with the question >> of what if a malicious client intentionally did not configure the room, >> but configuring the room does not make the problem go away. >> >> In fact, configured rooms present additional complications. If a user >> sends an occasional message to each room after its unlocked, this would >> also with little cost to the hacker would prevent the server from timing >> out and destroying the room due to inactivity. That's not an attack we've seen in the wild, as far as I know. > The solution is simple, a (service global) limit for ownerships in rooms. XEP-0045 doesn't cover service-global features. We've always said we might write a spec about that, though. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0045 1.25rc7
On 10/3/2011 8:05 PM, Mike Wacker wrote: I've checked a new provisional version of XEP-0045 into git... Latest diff: http://xmpp.org/extensions/diff/api/xep/0045/diff/1.25rc6/vs/1.25rc7 Diff from 1.24: http://xmpp.org/extensions/diff/api/xep/0045/diff/1.24/vs/1.25rc7 Rendered version: http://xmpp.org/extensions/tmp/xep-0045-1.25.html Continued feedback would be appreciated. /psa It may help to include the full end-to-end flow for discovering component support for MUC. Unlike other features, MUC often must live on a separate domainpart (chat.shakespeare.lit) than the one an entity negotiates a stream with (shakespeare.lit); otherwise it would be impossible to tell if ha...@shakespeare.lit/pda is a full jid or a room jid. In 6.1, the ha...@shakespeare.lit/pda send a disco#info request to chat.shakespeare.lit, but it never says how hag66 determined that chat.shakespeare.lit exists in the first place. Doing some digging around in XEP-0030, it appears that the answer would be this: 1. ha...@shakespeare.lit/pda issues a disco#items request to shakespeare.lit. One of the items returned is chat.shakespeare.lit. 2. ha...@shakespeare.lit issues a disco#info request to each item returned in (1). The disco request to chat.shakespeare.lit returns the muc feature. It might be helpful to list out those steps as well. In addition, I would assume that shakespeare.lit MUST NOT return the muc feature in a disco#info request, since it itself does not support the muc feature even though it has an item which supports the muc feature. Mike
Re: [Standards] XEP-0045 1.25rc7
Am 05.10.2011 21:56, schrieb Mike Wacker: On 10/4/2011 11:15 AM, Alexander Holler wrote: If the server never times out a room that is created but not configured and unlocked, then an easy DOS vector is to flood the server with room creation requests but never configure any of the rooms. Since these unconfigured rooms never time out, these creation requests will eventually starve the server of resources. Throttling won't work here, as it will slow but not stop the eventual starvation. Two mitigations would be to either time-out unconfigured rooms or put a cap on the number of unconfigured rooms a single user can create. You could also have a max cap of total rooms for all users, but that also has DOS implications because even if malicious users can't DOS the server, they can DOS other users trying to create rooms if they can hit the server cap. Whats the difference between unconfigured and configured rooms? It's as easy to DOS a server with configured rooms as with unconfigured rooms and it will cost a malicious client almost nothing to configure a room along with the creation. Regards, Alexander Good call, Alexander, my initial line of inquiry began with the question of what if a malicious client intentionally did not configure the room, but configuring the room does not make the problem go away. In fact, configured rooms present additional complications. If a user sends an occasional message to each room after its unlocked, this would also with little cost to the hacker would prevent the server from timing out and destroying the room due to inactivity. The solution is simple, a (service global) limit for ownerships in rooms. Regards, Alexander
Re: [Standards] XEP-0045 1.25rc7
On 10/4/2011 11:15 AM, Alexander Holler wrote: If the server never times out a room that is created but not configured and unlocked, then an easy DOS vector is to flood the server with room creation requests but never configure any of the rooms. Since these unconfigured rooms never time out, these creation requests will eventually starve the server of resources. Throttling won't work here, as it will slow but not stop the eventual starvation. Two mitigations would be to either time-out unconfigured rooms or put a cap on the number of unconfigured rooms a single user can create. You could also have a max cap of total rooms for all users, but that also has DOS implications because even if malicious users can't DOS the server, they can DOS other users trying to create rooms if they can hit the server cap. Whats the difference between unconfigured and configured rooms? It's as easy to DOS a server with configured rooms as with unconfigured rooms and it will cost a malicious client almost nothing to configure a room along with the creation. Regards, Alexander Good call, Alexander, my initial line of inquiry began with the question of what if a malicious client intentionally did not configure the room, but configuring the room does not make the problem go away. In fact, configured rooms present additional complications. If a user sends an occasional message to each room after its unlocked, this would also with little cost to the hacker would prevent the server from timing out and destroying the room due to inactivity. Mike
Re: [Standards] XEP-0045 1.25rc7
If the server never times out a room that is created but not configured and unlocked, then an easy DOS vector is to flood the server with room creation requests but never configure any of the rooms. Since these unconfigured rooms never time out, these creation requests will eventually starve the server of resources. Throttling won't work here, as it will slow but not stop the eventual starvation. Two mitigations would be to either time-out unconfigured rooms or put a cap on the number of unconfigured rooms a single user can create. You could also have a max cap of total rooms for all users, but that also has DOS implications because even if malicious users can't DOS the server, they can DOS other users trying to create rooms if they can hit the server cap. Whats the difference between unconfigured and configured rooms? It's as easy to DOS a server with configured rooms as with unconfigured rooms and it will cost a malicious client almost nothing to configure a room along with the creation. Regards, Alexander
Re: [Standards] XEP-0045 1.25rc7
On 10/3/11 10:58 PM, Mike Wacker wrote: > On 10/3/2011 8:05 PM, Mike Wacker wrote: >> I've checked a new provisional version of XEP-0045 into git... >> >> Latest diff: >> >> http://xmpp.org/extensions/diff/api/xep/0045/diff/1.25rc6/vs/1.25rc7 >> >> Diff from 1.24: >> >> http://xmpp.org/extensions/diff/api/xep/0045/diff/1.24/vs/1.25rc7 >> >> Rendered version: >> >> http://xmpp.org/extensions/tmp/xep-0045-1.25.html >> >> Continued feedback would be appreciated. >> >> /psa >> >> > Under 13.6, Denial of Service, we should also mention room creation. > We've listed a lot of bad things that can be done in a room, but we've > left out the room creation process itself. > > For example, just like one could register a lot of nicks to deny use of > them to others, one could also do the same with rooms if they send the > initial presence stanza presence to create the room but don't configure > it afterwards. We also say an implementation MAY set a timeout for > initial configuration of a room once its created, but from a security > point of view not setting a timeout could lead to resource starvation. > > If the server never times out a room that is created but not configured > and unlocked, then an easy DOS vector is to flood the server with room > creation requests but never configure any of the rooms. Since these > unconfigured rooms never time out, these creation requests will > eventually starve the server of resources. Throttling won't work here, > as it will slow but not stop the eventual starvation. > > Two mitigations would be to either time-out unconfigured rooms or put a > cap on the number of unconfigured rooms a single user can create. You > could also have a max cap of total rooms for all users, but that also > has DOS implications because even if malicious users can't DOS the > server, they can DOS other users trying to create rooms if they can hit > the server cap. Good points. I'll incorporate those into the spec. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0045 1.25rc7
On 10/3/2011 8:05 PM, Mike Wacker wrote: I've checked a new provisional version of XEP-0045 into git... Latest diff: http://xmpp.org/extensions/diff/api/xep/0045/diff/1.25rc6/vs/1.25rc7 Diff from 1.24: http://xmpp.org/extensions/diff/api/xep/0045/diff/1.24/vs/1.25rc7 Rendered version: http://xmpp.org/extensions/tmp/xep-0045-1.25.html Continued feedback would be appreciated. /psa Under 13.6, Denial of Service, we should also mention room creation. We've listed a lot of bad things that can be done in a room, but we've left out the room creation process itself. For example, just like one could register a lot of nicks to deny use of them to others, one could also do the same with rooms if they send the initial presence stanza presence to create the room but don't configure it afterwards. We also say an implementation MAY set a timeout for initial configuration of a room once its created, but from a security point of view not setting a timeout could lead to resource starvation. If the server never times out a room that is created but not configured and unlocked, then an easy DOS vector is to flood the server with room creation requests but never configure any of the rooms. Since these unconfigured rooms never time out, these creation requests will eventually starve the server of resources. Throttling won't work here, as it will slow but not stop the eventual starvation. Two mitigations would be to either time-out unconfigured rooms or put a cap on the number of unconfigured rooms a single user can create. You could also have a max cap of total rooms for all users, but that also has DOS implications because even if malicious users can't DOS the server, they can DOS other users trying to create rooms if they can hit the server cap. Mike
[Standards] XEP-0045 1.25rc7
I've checked a new provisional version of XEP-0045 into git... Latest diff: http://xmpp.org/extensions/diff/api/xep/0045/diff/1.25rc6/vs/1.25rc7 Diff from 1.24: http://xmpp.org/extensions/diff/api/xep/0045/diff/1.24/vs/1.25rc7 Rendered version: http://xmpp.org/extensions/tmp/xep-0045-1.25.html Continued feedback would be appreciated. /psa
