search

processone / ejabberd

Robust, Ubiquitous and Massively Scalable Messaging Platform (XMPP, MQTT, SIP Server)
https://www.process-one.net/en/ejabberd/
Other
6.07k stars 1.51k forks source link

SASL2 support (XEP-0388) #4112

Closed mremond closed 8 months ago

mremond commented 11 months ago

Add support to SASL 2 (https://xmpp.org/extensions/xep-0388.html).

Relates to #4107

licaon-kter commented 11 months ago

Will include https://github.com/processone/ejabberd/issues/3972 ?

prefiks commented 11 months ago

I added support for that (at least that part that that put that in features as part of tls-export implementation

Neustradamus commented 11 months ago

@prefiks: Good job!

Please add the XEP version supported in the code like other XEPs :)

Linked to:

Neustradamus commented 11 months ago

@mremond: A moment ago, I have done it here :)

prefiks commented 10 months ago

Commit efffc3142ae0768f34821b9529a9afd9976a22c3 adds initial support for this. This is not yet fully completed, right now only mod_stream_mgmt recognized inline request, i will also add support for this to mod_carboncopy and mod_client_state.

mzealey commented 10 months ago

Hi there, we were going to implement this ourselves in a few months precisely for the fast session resumption, but what you have done looks excellent so thank you @prefiks

One issue from our side in the testing: you have required that the connection is SSL terminated to ejabberd which is a reasonable enough assumption. However in our setup we terminate on a proxy layer in front of the ejabberd cluster (with a secure network between). Would it be possible for you to add a config option to force-enable sasl2 even if the connection does not seem encrypted to ejabberd itself?

prefiks commented 10 months ago

One issue with that will be that we will not be able to test validity of tls channel binding data, and that would require disabling -PLUS versions of authentication methods, it's something that could be done but it's something that you need to be aware of. But i guess option for that is something that can be added.

mzealey commented 10 months ago

Yes I mean obviously if we are not terminating TLS on ejabberd then most of those channel binding options are not available. Although as @inputmice has pointed out to me we could probably do the server-end-point one if we copied the tls certs to ejabberd. I don't see there's much functionality loss in just a blanket 'If this flag is specified, channel binding is disabled. Use Ejabberd's TLS implementation if you require channel binding'.

licaon-kter commented 10 months ago

@prefiks what's missing so this can be closed?

Neustradamus commented 9 months ago

@licaon-kter: Yes this ticket can be closed not the original yet.