jdev - 2022-05-30

How can I cache them?

Hi. Are there any articles or other places where I can see example(s) of s2s streams? I'm trying to build a minimal XMPP server to understand the protocol, but so far the behavior I'm seeing in the real world from different servers doesn't always align with the specs.

report any divergence from the specifications to the relevant software projects to get them fixed :)

https://xmpp.org/rfcs/rfc6120.html#examples-s2s

Take starttls for example: - jabber.ru doesn't *require* TLS, but messages I send don't get through to my client either - 5222.de (the one I'm writing this from) does go through starttls fine, but then sends me a dialback request that has my server domain in "from", on my outbound connection, wtf? - matrix.org requires TLS, but after TLS negotiation is done, closes the stream saying "Your server's certificate is invalid, expired, or not trusted by matrix.org" — what does this mean even? I don't receive an inbound connection from it. Am I supposed to provide a client certificate? Am I supposed to use my TLS server certificate for that?

you seem to be mostly confused about the abomination which is dialback

Yeah, dialback causes instant confusion. All the terms are backwards.

hm, okay, so does this actually mean that 5222.de wants me to verify its dialback key?

grishka@5222.de, in summary, your servers cert is probably wrong

Dialback is generally only used today when the cert is wrong somehow, e.g. expired or so

and for my toy server it would be fine to swap to and from around and add result="valid" and send that back?

That's also what the message from matrix.org points at

yeah well how *does* the other server get my server certificate?

grishka@5222.de, you need to send it as client certificate

the kind of TLS I'm used to only involves a single certificate, the one the server sends to the client

ah

ah okay

xmpp s2s may use mutual TLS, so you'll have to send the cert along

and then you may have to do SASL EXTERNAL to lock that in as authentication method

thanks, I'll try that (I'll have to go through the misery of dealing with Java's cryptography APIs either way, this just means I'll have to do it sooner than planned, lol)

https://xmpp.org/extensions/xep-0178.html#s2s might be handy

https://xmpp.org/extensions/xep-0288.html makes things even nicer and faster

After setting up a client certificate + private key (and cursing at Java cryptography APIs) I'm now getting a different error: <unsupported-feature xmlns="urn:ietf:params:xml:ns:xmpp-streams"/><text xmlns="urn:ietf:params:xml:ns:xmpp-streams">No viable authentication method offered</text> So the client certificate replaces dialback, right?

Huh

or probably I'm not doing the stream restart correctly, it's as if the receiving side doesn't expect me to send <stream:features> after restart

gotta read the RFC again

Unless you found a server other than Prosody producing that <text> message, it likely means _you_ did not offer TLS or SASL

Prosody says that for outgoing connections

Prosody → you. You're supposed to offer TLS or SASL

So, not about client certificates anymore

I did offer TLS, I did negotiate TLS, and then I received that error over the encrypted connection after only offering dialback 🤔

I'll try sending empty <stream:features/>

If the connection is secured it's expecting to be offered SASL probably

It's saying that if it gets a `<stream:features/>` without anything it knows how to handle, and the connection is not completed

I.e. it didn't do starttls, nor sasl, nor dialback

Due to the modular architecture, it has no idea why

still I receive: <stream:features><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>EXTERNAL</mechanism></mechanisms><dialback xmlns="urn:xmpp:features:dialback"/></stream:features> I send: <stream:features><dialback xmlns="urn:xmpp:features:dialback"/></stream:features> then I receive the aforementioned error

dialback _is_ a matching feature, so why is it not happy with that?

Dialback is not advertised in `<stream:features>` for historical reasons

So if no SASL is offered, it's probably assumed to be there and attempted. Unless the module is not loaded, or some reason.

grishka@5222.de, honestly if you implement TLS client auth (SASL EXTERNAL) you won't need to implement dialback today in 2022, but you need a trusted certificate from a CA

I tried not sending <stream:features> and sending <db:request> instead, now it feels like I'm getting further — I'm receiving an incoming connection from 5222.de that gets stuck at starttls because I don't implement the receiving end of that yet, so that's the next thing to be taken care of I guess

moparisthebest, it is a trusted certificate from a CA, it's a let's encrypt one I pulled out of my server

and you are sending it as your client cert on outgoing connections ?

yes

then dialback shouldn't even come up

And you're constructing the chain correctly?

Also, you may be interested in https://badxmpp.eu/

I guess what I'm saying is you should chase the bug in your TLS cert auth and forget about dialback, seeing a dialback attempt is just telling you your cert auth failed

Hm, wait

> I receive: <stream:features> > I send: <stream:features> on the same connection?

The party answering the connection sends stream features, not both

This all of course gets confusing when there are two connections involved

So it's a good idea to clarify which connections are involved

Zash oh thanks for badxmpp.eu