Details

      Description

      User sets and activates privacy lists to block iq stanzas:

      <!-- 16:20:02.256 OUT (::xmpp::1, user1@domain.tld/Ткаббер) -->
      <iq id='184:823142' xml:lang='en' type='set'>
          <query xmlns='jabber:iq:privacy'>
              <list name='blockiq'>
                  <item action='deny' order='1'><iq/></item>
              </list>
          </query>
      </iq>
      <!-- 16:20:02.347 IN (::xmpp::1, user1@domain.tld/Ткаббер) -->
      <iq from='user1@domain.tld' to='user1@domain.tld/Ткаббер' id='184:823142' type='result'/>
      
      <!-- 16:21:08.397 OUT (::xmpp::1, user1@domain.tld/Ткаббер) -->
      <iq id='186:791728' xml:lang='en' type='set'>
          <query xmlns='jabber:iq:privacy'>
              <active name='blockiq'/>
          </query>
      </iq>
      <!-- 16:21:08.460 IN (::xmpp::1, user1@domain.tld/Ткаббер) -->
      <iq from='user1@domain.tld' to='user1@domain.tld/Ткаббер' id='186:791728' type='result'/>}}
      

      User sends an iq stanza, which should be blocked:

      <!-- 16:23:32.003 OUT (::xmpp::1, user1@domain.tld/Ткаббер) -->
      <iq id='189:525572' xml:lang='en' type='get' to='user2@domain.tld/resource'>
          <query xmlns='jabber:iq:version'/>
      </iq>
      

      Server should block this stanza, and send back iq not-acceptable error stanza. (XEP-0016, example 51)

      Instead, the server routes it to contact, which responds:

      <!-- 16:23:32.099 IN (::xmpp::1, user1@domain.tld/Ткаббер) -->
      <iq from='user2@domain.tld/resource' to='user1@domain.tld/Ткаббер' type='result' id='189:525572'>
          <query xmlns='jabber:iq:version'>
              <name>Stabber</name>
              <version>666</version>
              <os>FiendOS</os>
          </query>
          <evil xmlns='http://jabber.org/protocol/evil'/>
      </iq>
      

        Activity

        Hide
        badlop Badlop added a comment -

        In your example, user1 sets an item with action=deny and child element=iq. Notice that this tells the server to block incoming IQ stanzas, not outgoing:
        http://xmpp.org/extensions/xep-0016.html#protocol-syntax

        <iq/> – blocks incoming IQ stanzas

        When user1 sends an outgoing IQ stanza, ejabberd acts correctly by allowing the stanza routing.

        And finally user2 sends an incoming IQ stanza to user1. According to the XEP, ejabberd must block this stanza, but surprisingly ejabberd does not. Probably because it is a Result IQ stanza, not Get.

        If user2 sends a Get IQ stanza to user1, then ejabberd blocks it.

        Please take a look at the details I mentioned. I consider this ticket to be Invalid. Do you agree?

        Show
        badlop Badlop added a comment - In your example, user1 sets an item with action=deny and child element=iq. Notice that this tells the server to block incoming IQ stanzas, not outgoing: http://xmpp.org/extensions/xep-0016.html#protocol-syntax <iq/> – blocks incoming IQ stanzas When user1 sends an outgoing IQ stanza, ejabberd acts correctly by allowing the stanza routing. And finally user2 sends an incoming IQ stanza to user1. According to the XEP, ejabberd must block this stanza, but surprisingly ejabberd does not. Probably because it is a Result IQ stanza, not Get. If user2 sends a Get IQ stanza to user1, then ejabberd blocks it. Please take a look at the details I mentioned. I consider this ticket to be Invalid. Do you agree?
        Hide
        hermitifier Hermitifier added a comment -

        While I don't say your reasoning is wrong, I do not fully agree.
        Now I see that protocol described by XEP is ambiguous.

        Firstly, this creates a situation in which outgoing query passes, but incoming reply is blocked, which could lead to leaks unless there are timeouts or such implemented.

        Secondly, the only outgoing stanza that can be blocked is presence. But description of outgoing stanzas, does not specify the stanza type. Even the example 51 shows server's reaction to outgoing message, which, by protocol, cannot be blocked.

        I think the ticket is not strictly invalid, at least not until the protocol is clarified.

        Show
        hermitifier Hermitifier added a comment - While I don't say your reasoning is wrong, I do not fully agree. Now I see that protocol described by XEP is ambiguous. Firstly, this creates a situation in which outgoing query passes, but incoming reply is blocked, which could lead to leaks unless there are timeouts or such implemented. Secondly, the only outgoing stanza that can be blocked is presence. But description of outgoing stanzas, does not specify the stanza type. Even the example 51 shows server's reaction to outgoing message, which, by protocol, cannot be blocked. I think the ticket is not strictly invalid, at least not until the protocol is clarified.
        Hide
        badlop Badlop added a comment -

        this creates a situation in which outgoing query passes, but incoming reply is blocked

        That's what the XEP says.

        However, ejabberd 2.1.5 and older have a bug: even if the active privacy list has a rule to deny incoming IQs, an incoming IQ reply (of type Result or Error) is allowed, not blocked.

        I've fixeda this XEP incompliance in ejabberd git now.

        the only outgoing stanza that can be blocked is presence.

        Right. Notice that in XMPP, Message and IQ stanzas are always directed to a specific recipient, but Presence stanzas also allow broadcast. So, the client can already control destination of Message and IQ itself; and can control destination of Presence broadcast destination by setting privacy lists in his server.

        But description of outgoing stanzas, does not specify the stanza type. Even the example 51 shows server's reaction to outgoing message, which, by protocol, cannot be blocked.

        Read http://xmpp.org/extensions/xep-0016.html#protocol-all
        That allows to block all incoming and outgoing stanzas, of any type.

        I've noticed ejabberd had a bug implementing that part of the XEP, and I've fixed in git now.

        With the bug fixes I've committed to git, ejabberd is now better compliant with the XEP. If you try and find any remaining bug, please report. However, I guess that if you aren't satisfied by the XEP, you will still be dissatisfied with ejabberd.

        Now I see that protocol described by XEP is ambiguous. ... I think the ticket is not strictly invalid, at least not until the protocol is clarified.

        The XEP will not disambiguitate spontaneously, you will have to bring the topic to the "Standards" XMPP mailing list

        Show
        badlop Badlop added a comment - this creates a situation in which outgoing query passes, but incoming reply is blocked That's what the XEP says. However, ejabberd 2.1.5 and older have a bug: even if the active privacy list has a rule to deny incoming IQs, an incoming IQ reply (of type Result or Error) is allowed, not blocked. I've fixeda this XEP incompliance in ejabberd git now. the only outgoing stanza that can be blocked is presence. Right. Notice that in XMPP, Message and IQ stanzas are always directed to a specific recipient, but Presence stanzas also allow broadcast. So, the client can already control destination of Message and IQ itself; and can control destination of Presence broadcast destination by setting privacy lists in his server. But description of outgoing stanzas, does not specify the stanza type. Even the example 51 shows server's reaction to outgoing message, which, by protocol, cannot be blocked. Read http://xmpp.org/extensions/xep-0016.html#protocol-all That allows to block all incoming and outgoing stanzas, of any type. I've noticed ejabberd had a bug implementing that part of the XEP, and I've fixed in git now. With the bug fixes I've committed to git, ejabberd is now better compliant with the XEP. If you try and find any remaining bug, please report. However, I guess that if you aren't satisfied by the XEP, you will still be dissatisfied with ejabberd. Now I see that protocol described by XEP is ambiguous. ... I think the ticket is not strictly invalid, at least not until the protocol is clarified. The XEP will not disambiguitate spontaneously, you will have to bring the topic to the "Standards" XMPP mailing list
        Hide
        hermitifier Hermitifier added a comment -

        OK then, I obviously misunderstood the standard, it's more convoluted than I thought.
        At least a related bug was revealed.

        Show
        hermitifier Hermitifier added a comment - OK then, I obviously misunderstood the standard, it's more convoluted than I thought. At least a related bug was revealed.

          People

          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development