XSF Discussion - 2018-10-15

jonas’: unless/until Cisco takes it away haha

anyone have a good suggestion how to validate that a listing of a service in disco#items is actually intended by the listed service? I’m asking in the context of muclumbus/search: it is easy for an adversary to list a service in their disco#items which is accessible via s2s, but which doesn’t want to be listed. For example, if someone wanted to host a "hidden" IRC gateway and someone else noted that, someone else could add it to their disco#items and thus un-hide it.

jonas’, you could possibly filter out items with an xmpp address not being a "child" address of the requested entity

flow, how would one determine that?

DNS-based? :/

xmpp address based?

and this means domainpart based

but maybe I misunderstand the question

and, yes, this becomes likely infeasiable if the domainpart is an IP address

but if you example.org announce muc.foo.org, then I'd filter it

right, so DNS based

it should be zone based though, and that’s tricky to do

and many not even be generally correct.

*sigh*

zone based?

you need to take into account authority breaks in DNS, i.e. delegations

jonas’, I'm curious, has this turned out to be a practical problem? Did someone complain?

co.uk. should not be allowed to advertise stuff for fnord.co.uk ;-)

no, nobody complained yet, but I’d like to play it safe with resources like IRC gateways

which are easy to abuse

or may be easy to abuse

or something

pep. pre-emptively complained when I threw the idea of listing IRC gateways around in some MUC

jonas’, I'm not sure about this, isn't the parent domain is always able to redirect your users?

flow, with an attack on DNS, yes.

with an attack on DNS, you can do a lot of things

jonas’, no

just because it's your parent domain

you have to trust it anyways

I’d count "replace NS records with something I don’t intend them to be" as an attack :)

even if they have the power to do so by design

so you trust them to not do that, but you don't trust them to announce your services?

bbl, SIGFOOD

I think my preferred way would be to require the child-components disco#items to also include the parent-service, but that’s probably infeasible.

gl

jonas’, really I shouldn't have to wait that you start listing them to filter traffic if I don't want people to use it, but you're the force pushing me to atm :P

I know my gateway is not used by anybody I don't want to, for the moment

pep., if you don't want your gateway to be used by other entities on the network it surely provides an options to restrict its usage to local users only?

flow, I want _some_ s2s users to be able to use it, so mod_firewall, plus additional tricks for disco#items maybe

pep., allright, so whiteliste the entities that are allowed to use it. Doesn't that solve the problem?

probably, I just need to do it. I didn't need to until now

(And I know that whitelisting can be tricky, depending on the used software. But hiding isn't a solution either)

pep., I'd argue that you needed to do it before too

Well I've been somewhat monitoring access to that and it's not being abused

But yeah I agree

pep., that could change now, especially since you mentioned publicly that you run an open gateway :-P

I think it is askin to running an open mail relay

I know

*akin

I don't especially agree with the open mail relay thing

It's not like I was running an open j2j gateway

You could want to run an open IRC gateway, and some services do already

(And eventually I may open that gateway as well)

pep., I have a set of mod_firewall rules which do that (allow all local users + s2s whitelist)

jonas’, yeah, working on it

pep., %LIST whitelist: file:/etc/prosody/fw/data/biboumi-whitelist.txt %ZONE biboumi: irc.zombofant.net ::deliver ENTERING: biboumi ENTERING: $local NOT CHECK LIST: whitelist contains $<@from|bare> LOG=[debug] dropping inbound message to biboumi from $<@from|bare> BOUNCE=forbidden (You are not allowed to access this host.) ::deliver_remote LEAVING: biboumi NOT TYPE: error NOT CHECK LIST: whitelist contains $<@to|bare> LOG=[debug] dropping outbound message from biboumi to $<@to|bare> BOUNCE=forbidden (The destination is not authorized to access this host.)

hm, maybe it would make sense to require publicly listed gateways to publish contact information.

hrm, so there’s no way to detect MIXness of a group chat service from the identity alone?

jonas’, I think this is by design (but could be wrong)

> hm, maybe it would make sense to require publicly listed gateways to publish contact information. jonas’: Contact Addresses would fit, but it must be in a server info dataform

Ge0rG, I’m confused

that’s exactly what I was talking about?

but you make it sound like it would be a problem

I'm not a disco specialist, do components come with a http://jabber.org/network/serverinfo record by default?

what is that?

xep 157 ?

ah, that

right

Ge0rG, probably not, but they should

How many data forms can you fit into one query result?

Ge0rG: unbounded

Ge0rG, given that conference.jabber.org returns ALL the rooms in a single disco#items, I think we’re good.

(and I think you can see when muclumbus queries conference.jabber.org in the traffic graphs because it creates a fun spike)

Zash: speaking of real life implementations.

(and then it discards the result due to malformed JIDs *shrug*)

this kills the terminal

Ge0rG: You can have more than one dataform, like you can have more than one identity and more than one feature

I think I've seen at most two forms

... maybe I did that myself tho, not sure

Zash: I've had a look into how poezio processes such a response. I vaguely kept my sanity.

Ge0rG, https://lab.louiz.org/louiz/biboumi/issues/3388 ;-)

jonas’: 👍

jonas’: I was about to open an issue in biboumi for 157 but was distracted and now someone already did it

"someone" :)

SOMEONE

Hm, do MUCs commonly have 157?

Zash: I can't imagine. Should they?

Why not?

Ge0rG, a contact for an admin when you’re facing an attack in one of your room seems useful

They could..

I honestly never put contact info on components

jonas’: on the MUC domain? Sure, would be good

(as long as you dont service the muc alone)

(i suppose ppl will look at the upper level domain info)

that’s not a good thing to do automatedly though

I have that server_contact loaded on every single vhost/component fwiw

I have it integrated in mod_disco but not every component will use it so (also external components wont at all) it can be tricky for those anyways