XSF Discussion - 2018-07-23

Link Mauve: sorry for blaming you yesterday. You were not at fault. It was an obscure bug in smack3's handling of unknown stanzas.

Ge0rG, no problem. ^^

I was surprised because I wrote these modules very defensively.

Who could have expected that `parseIQ()` returns the parsed IQ for most cases, except for a GET or SET with unknown payload, where it just injects a not-implemented response and returns null.

s/smacks3/smacks4/?

no idea how smack4 does it

Smack 3 has no support for stream management, I assume we are talking about a patch someone put on top of a Smack 3 codebase

flow: yes, a patch that's using Connection.addPacketListener() to keep track of stanzas.

Ge0rG, let me know if you ever want to switch to a recent release of smack and need help

I think both of that is the case :)

flow: I'm grateful that you took the time to integrate smack4 back then, and I'm sorry that it happened on an oldish branch and I never managed to forward-port it.

flow: I really want to switch to most recent smack4, and I don't have illusions about the required effort.

o/

Guus ^_^

\o

I'd like to do some interop testing

does someone has a server available that does S2S over DirectTLS?

metre might be able to do such a thing

Guus: conversations.im

.oO(S2S over DirectPlay) ✏

snap out of it! 😃

thanks Holger

Guus: I have mod_net_multiplex loaded on xmpp.yaxim.org:443, but IIRC not in the SRV records.

Thanks Ge0rG. I was just checking for SRV records on conversations.im 🙂

Ge0rG: That way you can do TLS-on-connect for s2s connections?

Holger: I hope so

itym you wish

Somebody could attempt an s2s handshake there.

I don't see why it wouldn't work

if I only knew the xmlstream namespace by heart

MattJ: Well it won't teach Prosody to do XMPPS for outgoing connections, will it?

No, not for outgoing

MattJ: For incoming connections, EXTERNAL auth and/or Dialback will be fine?

Yes?

Nice :-)

Ge0rG, appears to work

SENT: <stream:stream xmlns='jabber:server' xmlns:stream='http://etherx.jabber.org/streams' version='1.0' to='yax.im'> RECV: <?xml version='1.0'?><stream:stream xmlns:db='jabber:server:dialback' xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en' from='yax.im' id='b63d1089-0aa0-4bd4-b5b4-4deb3efe83e2' to='' version='1.0' xmlns='jabber:server'><stream:features><dialback xmlns='urn:xmpp:features:dialback'/></stream:features> SENT: <stream:error><undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'/><text xmlns='urn:ietf:params:xml:ns:xmpp-streams'>no</text></stream:error> RECV: </stream:stream>

even without xml header :-X

The XML header isn't mandatory

Guus, dave.cridland.net should have XEP-0368 on inbound and outbound, and use the right SRV records.

Dave, excellent, as you might be the one reviewing this new Openfire code 🙂

Guus, If you want to set up your own test, then it's just Metre, and I can help you figure out a config file to let you ping Metre on its own.

Thanks, maybe later Dave. Right now, I'd like to see if I can test this without adding another new component to the mix

also, crappy camping wifi /me raises fist

Dave, we miss you in open_chat, by the way

Pft, I just got back from a camping trip with no wifi and no phone signal

"In my day, we rocket-jumped to school and back!"

well, failure on both ends 😞

but I'm still using a self-signed cert, that probably doesn't help

right, using a proper certificate made all the difference. I think that directTLS from Openfire to dave.cridland.net and conversations.im is now working.

If someone would be willing to shoot some (direct TLS) s2s tests at goodbytes.nl, I'd be grateful.

Guus, It looks like movim.eu is also using XEP-0368 - unless I can't read my own logs.

No SRV record found for: _xmpps-server._tcp.movim.eu.

Guus, Yeah, but it seems to use it to me. Maybe.

that's entirely possible

for the record, I've disabled the lookup of _xmpp-server on goodbytes.nl, to force _xmpps-server lookups for the purpose of this test.

Guus, I found one tricky bit was to combine the two SRV lookups into a single one for the purposes of the SRV selection algorithm neatly.

Guus: why is it offering starttls when you connect on port 5270?

Dave, why not do two SRV lookups and combine the results manually?

intosi: because the code is a mess and I didn't add a proper condition there, most likely.

Fair enough.

Openfire's S2S code is using the pre-Java NIO blocking way of doing things. We've ment to replace it ages ago, but it continues to survive. Now this is bolted on

it's not pretty...

Old code doing things that aren't pretty, a fate not unique to your code ;)

I think I fixed it. I'll redeploy

Grand :)

intosi, mind trying again?

linkmauve, Openfire thinks it's funny that your cert chain contains multiple certs with identical IssuerDN's

Looks good to me, thanks!

Guus, check.messaging.one too.

thanks guys

Link Mauve, I _think_ that the reason for Openfire to complain about this is that it tries to recreate the chain (matching subject and issuer of individual chains). That works around a problem where chains were provided out of order, iirc.

it now picked the last cert in the chain, as that's typically the EE cert.

Oh, my renew script uses cat twice; why?!

two cats are better than one

two cats is obviou...whathesaid

Guus, better now?

Link Mauve, yes it stopped warning me.

I think we did StartTLS and not DirectTLS, by the way

_xmpps-server._tcp.linkmauve.fr does not seem to exist.

Yes, indeed.

I don’t do legacy TLS on this server.

ok, but that's what I was testing in the first place 🙂

"legacy TLS"? What's that now?

Yeah, Openfire sadly refers to direct tls as 'legacy' in various places too 😞

I think we even have an issue for that, to change that into 'direct'.

because it was used on port 5223 for clients before starttls became a thing

stems from the introduction of StartTLS that was considered the new holy grale, replacing everything else...

Yeah. We were naive back then.

Guus: > using a proper certificate made all the difference. I think that directTLS from Openfire to dave.cridland.net and conversations.im is now working. conversations.im should also accept Dialback auth, by the way.

And we're not now

🙂

Holger: I was forcing direct TLS

Guus: Shouldn't Dialback auth work with direct TLS?

Holger, yes, but with direct TLS, you didn't like my self-signed cert, I think. Didn't even get to start dialback

Hmm, maybe something wrong on our side. I'll check.

if somethings wrong, it's probably on this side 🙂

But I remember at least one versions of Openfire and ejabberd not being big friends when it came to Dialback auth in the past.

Forgot the details, and whether the issue was resolved at some point.

Holger, that's probably many moons ago.

*at least old versions

Guus: Yeah may well have been fixed long ago.

Holger: if you do find new issues, please let me know

Will do.

Dave Cridland: > but it seems to use it to me. Yes all recent ejabberds will attempt direct TLS if DNS tells them to do that.

Holger: do you prefer that over StartTLS, or do you adhere to prio / weight of SRV records?

We adhere to the prio/weight, I think the XEP tells you to.

> Both 'xmpp-' and 'xmpps-' records SHOULD be treated as the same record with regard to connection order as specified by RFC 2782 [3], in that all priorities and weights are mixed.

> This enables the server operator to decide if they would rather clients connect with STARTTLS or direct TLS. However, clients MAY choose to prefer one type of connection over the other.

But you're not a client! ;-)

exactly.

'peer' 🙂

just wondering. So it's a coincidence that you did directtls with dave

assuming he has both SRV records, I didn't check.

Ah he has both, but both with the same prio/weight.

Just checked, in that case (same prio/weight) we prefer direct TLS indeed.

why? shouldn't you do 50/50?

Faster

It's arguably better and if the admin didn't set a preference (which I would respect) I'd prefer direct

sure, but still - if the SRV records are set up with the same prio/weight, shouldn't the connection attempts be distributed evenly?

According to the xep which says combine the two the answer is yes

But I don't agree

(I am also still against that wording and think it makes no sense to combine the two)

I mean honering the prio makes sense

But honering the weight doesn't

I'm not sure it'd be a good idea to deviate from standard SRV semantics, if we use them.

Weight is load management. And why would you manage load between direct and start

sure, but then instruct/suggest to admins to use different prio's

(or: don't combine the two, sure)

Guus: Yes, strictly speaking you're right of course.

Holger, I don't think I am. They're different SRV records. It's only because the XEP tells us to combine them, ...

(records for different services, I mean)

Guus, there is no such thing as "standard SRV semantics" when mixing two types of SRV records

that’s an invention of XEP-0368

jonasw, that's pretty much what I just typed 🙂

Yes I mean you're right that it goes against the XEP words to prefer one type.

or intended to, at least

what

I am not sure whether my client has shown your messages before it has shown mine

*shrug*

jonasw: The XEP tells you to mix the records as if both were of the same type, and to then apply standard SRV semantics.

jonasw: just nod and agree with me that I was wrong 🙂

I’ll just walk away and water the plants instead! ha!

jonasw, how often did we ask you to not water the plastic plants?!

Guus, those ain’t plastic!

https://uc.xmpp.zombofant.net/1af3e64c-98e4-4f39-b92b-df826fe9a97a/IMG_20180723_170548.jpg

2 megabytes? I hope those will be some nice plants

Once I've finished downloading that in like half an hour

daniel, https://uc.xmpp.zombofant.net/b607154c-4bec-495e-a513-3a3521a2b192/foo.jpg is that helpful? :)

if we had SIMS deployment, I could’ve uploaded multiple versions (or have my server rewrite that)

Holger, If the prio/weight is the same, what does it mean to "prefer" one? You bias the weight, or are you using weight like priority?

Dave Cridland: No I meant if there's an _xmpp-server. and an _xmpps-server. record and both have the same prio and the same weight (like you have for your server), we'll prefer the _xmpps-server. record. While the XEP tells us not to do this but to choose one at random instead.

So what do you do if the _xmpp-server has weight 4, and the xmpps_server has weight 5?

Do you not choose one at random then?

Then we do :-)

hm

that’s a very weird corner case you’re constructing there

Holger, What, so you're literally special-casing equal-wieght?

Oh! Ignore me.

I would’ve understood if you preferred direct TLS on equal prio, but ... special casing equal weight is weird

Well don't ignore me :-)

(FWIW, I could totaqlly go along with that when all weights are zero)

Dave Cridland: Yes exactly. _xmpps-server is only preferred if the weithts are zero.

Sorry.

Holger, Ah! OK, that makes sense - you're faced with something illegal so you take a policy view.

refresh my memory, why is it illegal?

jonasw, Because you're meant to randomly select a specific record ( weight / [total weights] ) of the time.

yes

jonasw, If all weights are zero, then you're picking each record 0/0 of the time.

jonasw, However, a weight *can* (and should, maybe) be zero if it is the only one - and that might occur by accident if there's only one *each* of _xmpp-server and _xmpps-server.

hm

the text in RFC 2782 (DNS-SRV) actually tells you how to deal with (even multiple) records of weight zero, even in presence of records which have non-zero weight

> So it's a coincidence that you did directtls with dave So turns out the answer is "yes", after all.

jonasw, Yes, indeed. So "illegal" is an incorrect assertion. But still, Holger's "if everything is weight zero, do TLS" is fine.

but DNS-SRV allows for "additional weighting information"

in which case everything said there about how weights are used is irrelevant it seems

Well. XEP-0368 says (I paraphrase) combine all the SRVs and then do RFC 2782.

Dave, I've got that XEP-0368 PR up for you to review, btw 🙂

still trying to lure you back in...

Guus, Yeah, I might even get to that.

Guus, Doing it now in fact.

\o/

(maybe have tissues ready for the occasional wiping of tears)