XSF Discussion - 2023-08-22

ok now i see a face there

Hi!

Hello

How common is direct tls s2s support these days? Do we have any sense?

inbound or outbound?

outbound I think? Like, if I run a server that supports only direct tls s2s with no starttls option can I talk to some people? many people? most people?

I'm not sure if prosody supports outbound direct TLS.

which would be a major share of the network ✏

It does, which makes at least prosody and ejabberd

43% of the servers tested on compliance.conversations.im support direct tls https://compliance.conversations.im/test/xep0368/

singpolyma: so I think you'd be able to talk to everyone running prosody 0.12+ and ejabberd (no idea on version)

lissine: that test is probably c2s though

moparisthebest, with tweaks or with reasonable default config?

> lissine: that test is probably c2s though I guess so

> moparisthebest, with tweaks or with reasonable default config? I think by default but now I'd have to look ↺

Check if you can ping xmpp:xmpps-only.badxmpp.eu

Also the servers that are not tested are less likely to have it, since it's not the default on prosody for example. So the real number is less than 43% But the most popular public servers do have it

Zash: I can, with my defaults prosody 0.12 setup

The real number is *much* less than 43% becasue the test is for c2s only

On a server that didn't support it I guess I'd get the dreaded half-s2s right?

singpolyma, plausible

XEP-0288 to the rescue?

https://github.com/iNPUTmice/caas/blob/master/caas-app/src/main/java/im/conversations/compliance/xmpp/tests/XmppOverTls.java#L44

> How common is direct tls s2s support these days? Do we have any sense? Openfire supports it, but there's a bug somewhere that we haven't tracked down yet. I'm hoping that with the rewrite that we're doing, it magically disappears...

Zash: yeah, but even fewer servers support bidi

Openfire does not do bidi at all.

Deploy more bidi!

I for one enjoy being able to do s2s from my laptop on the go :)

bidi would solve a few other things for me, but I didn't need to ask if it was an option becaue I know even prosody doesn't by default yet, right?

It's included in the latest release but not enabled by default

maybe in 0.13 ;)

or dare I call it... 1.0? ;) ;)

1.0 delayed another decade

😂

Hm, sampling from the Prosody at conference.prosody.im, I see 60% s2s connections using port 5270

60% 5270 39% 5269 and some random other ports

Probably skewed by various factors

Massaging the data to account for some of that, I get 63% 5269 35% 5270

DNS SRV lookups give an even chance of 5270 and 5269 usage?

on https://compliance.conversations.im/test/xep0368/ isn't it wierd that it says on July 6th, 60% passed, while on the top of the page it says 43% servers compliant?

The *Conversations* Compliance checker moves in mysterious ways

lissine: yes that metric is a bit weird. The graph only shows publicly listed servers. The other one is for all servers we have in our database

singpolyma: just curious what's your use case for direct TLS only?

whats the problem with servers not supporting direct tls?

i always thought start tls is the more complicated thing, where you need to upgrade the connection

is direct tls more secure? because from understanding it should protect from downgrade attacks no?

since it tries only tls

It's not more secure *if* you implement starttls right

noted

But if you allow plaintext connections too then yes it's more secure

Modern things that require encryption should implement starttls like "send the plaintext stream header and request to upgrade to TLS, completely ignore plaintext response, start upgrade to TLS"

The vulnerability comes from trusting the plaintext response when it says "nah we should just do plaintext instead"

so the only reason we implement starttls is because compatibility right?

Right

ack

Starttls is from a time when the ietf wanted to only hand out 1 port per protocol, and still support encrypted and not encrypted connections

It *also* solved the problem the TLS SNI extension solved differently later

If anyone designed it today no one would design starttls, but it made sense at the time

so as usual the tech community wants to die with the old stuff. meh :/

tl;dr you can always blame everything on changing requirements :)

> so as usual the tech community wants to die with the old stuff. meh :/ Well I don't think so, another decade and we'll be able to turn it off :) ↺

hopefully. i mean i dont mind things going slow.

Actually directtls probably needs a default port before we can do that...

as long as we get somewhere

ah right

I'd of course suggest 443 but others won't agree :/

but wouldnt that mean we do directtls over http?

https*

No with alpn port 443 should multiplex appropriately

ah so we still do xmpp but we hijack the port

interesting

old world: each protocol has a dedicated port, evil networks easily filter ports/protocols they don't like new world: each protocol goes over TLS/QUIC on port 443 with a dedicated ALPN, evil networks with more advanced equipment filter protocols they don't like near future world: each protocol goes over TLS/QUIC on port 443 with a dedicated ALPN using ECH, all protocols look identical to evil networks, screw you surveillance states

me: can we remove ports? who cares about numbers

yea that's the new/future world, no one cares about numbers, everything is 443 :P

ironically gnunet removed IPs, removed tcp, removed DNS but kept ports oO

Idea: XEP-0288 as part of advaced server core compliance in XMPP Compliance Suites 2024

Idea: XEP-0288 as part of advaced server core compliance in XMPP Compliance Suites 2024

wait thats an addon??

never saw that xep before

I'm mildly opposed to it, but not enough to veto such a move (if we want it adopted, adding it to the compliance suites is definitely sensible)

Not that I'm on council/can actually technically veto such a move :)

MSavoritias fae.ve, XMPP traditionally uses a pair of connections for s2s (incoming + outgoing). So if I send a stanza to you, my server will open a connection to your server and send the stanza over that.

ah. noted. havent read the standard yet ^^'

XEP-0288 is an optimization that means if you already have an incoming connection from a remote server, you can just use that to send a stanza instead of opening a new connection

It potentially halves the number of open s2s TCP connections

yeah. why is not adopted then? complexity?

or maybe its not a big enough optimization for people to care

My problem with it is that it can mask broken setups

As someone just pointed out, it technically allows you to s2s from behind a NAT and have everything work

...or appear to work

> My problem with it is that it can mask broken setups This is also my problem with it ↺

ah. ok

Everything would appear to work, but if someone tries to message you from a server you haven't already connected to, that will fail and you'll have no idea

Server A and server B can have perfectly working connections with conversations.im but won't be able to make a connection between themselves, ugly

> singpolyma: just curious what's your use case for direct TLS only? moparisthebest: hosting providers that provide automated TLS termination

> so the only reason we implement starttls is because compatibility right? I honestly prefer starttls I think it's a better solution technically. But HTTP refused so now we have a "standard starttls" called SNI and it's most of what you need in most cases, and it's so popular now (because of http) that many providers do it for you automatically

Ah ok you need it then, I was hoping you'd say "I only have 1 port" and I was gonna say "ok then multiplex" :)

> Actually directtls probably needs a default port before we can do that... Default ports are a historical artifact IMO, we have SRV now

Right but we can't just break half the network

Someone deployed a server years ago, keeps it up to date, it always just works, they didn't bother creating srv records, now we drop starttls and their server just stops working? Kinda gross

> As someone just pointed out, it technically allows you to s2s from behind a NAT and have everything work If you're veeeery careful this is an advantage ;)

moparisthebest: oh, right, I'm not in favour of dropping support for startls or standard port

But I wouldn't create a new standard port for new stuff

Just use SRV for new stuff

Any my proposed direct-tls-only setup will still be able to talk to starttls-only servers. Just so long as they can talk direct-tls on their outgoing leg

Right

But by "standard port" I mean "try this as a last resort if all else fails" and I think that's sensible, I just do it in xmpp-proxy, 443 for direct TLS and quic ✏

IMO if you don't have any direct tls SRV advertised then you don't have direct tls. Falling back doesn't seem advantageous to me. If you want it on 443, add a record that points at 443

Keep in mind DNS is trivial to block

Not if you DoH ;)

a better question is now though: whats the threat model we are trying to solve :)

ie it's perfectly feasible you'd find a network that filtered SRV records but not TLS on 443

I'm not very concerned about hostile networks that are actively trying to block. But I'm also mostly talking about s2s here where that's very unlikely to be the case

It's not much of a "threat model" per-say, but my guiding philosophy is the user always wants to connect to their server no matter what and since there is absolutely no harm to trying hardcoded ports as a last resort, and a chance they might work, just do it

I'm not against xmpp-proxy doing that, but I don't know that it warrants officially blessing 443 by an XEP

I've long threatened/promised to write a "srv best practices" type XEP, maybe it should just go there

yes, as an informational note in such xep I would support it I think

> old world: each protocol has a dedicated port, evil networks easily filter ports/protocols they don't like > new world: each protocol goes over TLS/QUIC on port 443 with a dedicated ALPN, evil networks with more advanced equipment filter protocols they don't like > near future world: each protocol goes over TLS/QUIC on port 443 with a dedicated ALPN using ECH, all protocols look identical to evil networks, screw you surveillance states Congratulations, you handed over everything to OpenSSL. ↺

s/OpenSSL/rustls/ :)

or libressl

No that's just OpenSSL

(its not)

> My problem with it is that it can mask broken setups Moving from Dialback to SASL EXTERNAL already did this, sorta. ↺

but it's maintained by openbsd, so not the same

its not the same codebase either anymore

Zash, it did move things in that direction, yes. But even with EXTERNAL the potential network issues are very visible when they occur. If I can't connect to you, I can't send a message to you. Ever.

With bidi, successfully sending a message to someone no longer means that you can successfully connect to them. So sometimes it might work, and sometimes it might not.

lissine, MSavoritias fae.ve: libressl has the same notorious foot gun API as OpenSSL which is 90% of the problem, being written in C is the other 10%, from that perspective they are the same

MattJ: what if, when you are the incoming end of a bidi connection, you try to establish an outgoing connection to that server and if it fails you notify the admin of remote server over the bidi connection you have, if successful just close it?

> lissine, MSavoritias fae.ve: libressl has the same notorious foot gun API as OpenSSL which is 90% of the problem, being written in C is the other 10%, from that perspective they are the same I agree about the C part. I was just pointing out they are not the same :) ↺

moparisthebest: yes, that is a potential enhancement we have discussed and could explore with implementation

We'll call the XEP bidi: trust but verify

I like it

Can't we like update the xep and make bidi the standard? Bidi saves a lot of screen real estate.

Trung: what kind of screen real estate?

We're talking about saving TCP connections, which is unrelated to anything you see on your screen, unless you run netstat. And even then any terminal can scroll 🙂

~6inch in the pocket thingy

moparisthebest, MattJ: I've tried to do such checks upon connection establishment to verify connectivity (for SASL EXTERNAL half-brokenness actually) but got into loops or deadlocks mostly

I guess you all know that images in public anonymous MUCs leak IP adresses so the muc is not anonymous anymore. What do you all think about this behavior?

Not great, but if you require user action before loading them it's the same as any URL. We've had talks about providing some proxy clients can fetch things via.

Anything that isn't inband will leak IP to *someone* unless you use tor