XMPP Service Operators - 2022-10-06

i don't know if it's right place for this question, sorry if it's not:

is there any site that monitors xmpp servs uptime?

You mean, the duration?

kuba_, if you want to know the current status and history of a public server's uptime, this may be useful: https://status.conversations.im/

If you run a server and want to monitor it, this may be useful: https://observe.jabber.network/

If you want to do a quick check of any server: https://xmpp-connectivity-check.mwild1.repl.co/

MattJ: tyvm. 1st link is what i needed

https://status.conversations.im/historical/ to be exact

There are also some other Websites in the wildy that track that.. But I don't have the links anymore...

thanks Menel!

Found it https://www.jabberes.org/servers/servers_by_uptime.html

Not quite up to date anymore it seems

Menel: thx anyway

General FYI: I've relocated https://xmpp-connectivity-check.mwild1.repl.co/ to https://connect.xmpp.net/ (shorter URL and more trustworthy host 😉)

Test took 0.3338691517710686 seconds

What a precise time 👌

string.format('%.16f', t) ?

pressing [enter] in the input box does not submit the form

...and it demands I identify ducks in pictures to view the source code

but you don't give a duck?

_after_ being cloudwalled

Ge0rG: not even a flying one

somewhat relatedly, I can't seem to duckduckgo documentaion for foorl... or indeed anything relevant at all

foorl is just the bot's name, the code is at https://github.com/horazont/xmpp-crowd

mjk, browser menu -> view source

d'oh!

Ducks identification is one reason I'm moving it

thanks both Ge0rG and MattJ

ah, so %.16f is how o.j.n formats the response json

or some equivalent

Okay, pushed some visual improvements, submit on enter, and some rounding on the test duration :)

👍️

\o/ ✏

Haven't fixed the source link, I'll do that once I've actually moved to a new repo

it could just link to view-source: fwiw :D

It could, but I'm not sure if that is a standard across browsers... :)

right

> On 25 May 2011, the 'view-source' URI scheme was officially registered with IANA per RFC 4395.

So...!

orrr serve the same page as text/plain!

oh, also noticed there's no <noscript> warning that js is required

"Connection failed!" 😥

now that I enabled js, same here

Connection failed to what?

snikket.chat

hm. dev.snikket.chat works

snikket.chat isn't an XMPP service, so that's expected

sry for the noise then :)

MattJ, IN SRV 0 0 0 . ?

Could do, yes

MattJ: Connection failed to a test host that doesn't serve XMPP. What I wanted to point out is that there is no specific error message about what went wrong

Sure, it's just meant to be a quick "is it up?" tool

Once the new xmpp.net is live, it can link to that for more advanced information

xmpp:no-service.badxmpp.eu has `IN SRV 0 0 0 .` so could compare with that

But without DNSSEC clients/servers shouldn't trust that and should attempt to connect anyway

Sigh.

Does it make a difference? Without DNSSEC there are many other ways to mess around with the results and stop clients successfully connecting.

I think you're just saying, "DNSSEC should be used" :)

Well it should be but if the domain doesn't have it enabled... Still shouldn't trust it

There are many ways yes, but also highly likely an attacker that can mess with DNS can't or doesn't block other connections, no harm in trying

But that's just the same as saying it shouldn't trust anything without DNSSEC

Other direction! Don't connect to anything without DNSSEC!

> But that's just the same as saying it shouldn't trust anything without DNSSEC Right, we don't trust, we verify, in the srv records existing case that means checking the cert names match the original domain name, in the srv record . case that means connecting anyway

Good point, but it makes no practical difference in this case

The point of injecting '.' would be to deny access to a legitimate domain. If the client ignores that, the attacker should just inject an invalid SRV target instead.

Cert verification will fail, but... access successfully denied

Either way there is no harm in trying to connect directly to 5222/5269 and 443, it might get through

Depends whether there is an attacker messing with your DNS :)

You're saying "Just always ignore SRV records"

It's not unique to SRV though - they can just mess with A records

No, I'm saying we never trust them anyway, why would . be deserving of special trust

Fallback was a mistake, we should have mandated SRV records

. isn't deserving of special trust, it's treated equally and the effect is ultimately no better or worse than an attacker modifying any other DNS response

If anything, denying a connection is safer from a client perspective than being redirected to an attacker's server (which may gather IPs, or host some TLS exploit, or whatever)

> <Zash> Other direction! Don't connect to anything without DNSSEC! Aka any .im domain 😏

,oO( .IM TLD DNSSEC DLV DANE XMPP TLSA RR )

Nobody noticed me accidentally roll out broken DNSSEC for *.snikket.chat this week (except observe.jabber.network, kudos). I think we have a long way to go until DNSSEC saves anyone :)

how do you call a long way that's getting longer faster than you move along it?

``` ~# dig ds im. ; <<>> DiG 9.16.29 <<>> ds im. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27924 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;im. IN DS ;; AUTHORITY SECTION: . 882 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2022100600 1800 900 604800 86400 ```

Ge0rG: DNS Adventures in Mirror World?

For a second you illuded me, I could get an answer to that

Maranda: https://op-co.de/blog/posts/yax_im_dnssec/

That was around 2016, before DLV got ditched due to widespread availability of DNSSEC

hehe

> Currently, StartSSL and WoSign offer free certificates, and Let's Encrypt is about to launch. This is ancient!

StartWHAT and WhoSign?

WHO? That escalated quickly!

vaccine certs?

> Nobody noticed me accidentally roll out broken DNSSEC for *.snikket.chat this week (except observe.jabber.network, kudos). I think we have a long way to go until DNSSEC saves anyone :) Which is unfortunately why my already implemented but not written down in XEP form discovery for QUIC doesn't use DNS but instead an https request like host-meta.json :'(

But at least it has a flag where if it's set means you don't need to do any srv or posh lookups at all...

Yes, please write that spec :)

> <moparisthebest> > Nobody noticed me accidentally roll out broken DNSSEC for *.snikket.chat this week (except observe.jabber.network, kudos). I think we have a long way to go until DNSSEC saves anyone :) > > Which is unfortunately why my already implemented but not written down in XEP form discovery for QUIC doesn't use DNS but instead an https request like host-meta.json :'( So you reinvented a dot well-known?

No, it would be included under .well-known, like the existing host-meta

Yep, actually I just crammed more stuff in the existing host-meta.json