[gnutls-devel] [PATCH] gnutls-cli won't work with ejabberd

[Nikos Mavrogiannopoulos]

On Thu, Jul 6, 2017 at 4:31 PM, pitchum <pitchum at gramaton.org> wrote:
> Hi,
>
> I'm currently trying to debug XMPP federation problems involving TLS
> negociation between prosody and ejabberd. gnutls-cli works fine with
> prosody but not with ejabberd.
> I've patched gnutls to workaround this and now my local gnutls-cli is
> able to communicate successfully with ejabberd (and prosody of course).
>
> My patch fixes 2 different problems.
>
> 1. ejabberd requires a different XML namespace whether you want to
> establish a c2s or an s2s connection while prosody is not so demanding.
> xmls='jabber:client' or xmlns='jabber:server' respectively.
>
> 2. ejabberd seems slow to answer to the first request. On initial
> request, prosody replies both <stream> and <features> in one shot.
> ejabberd immediatly replies <stream> only and gnutls-cli would have to
> perform another socket read to fetch <features>.

Thank you for the patch. I no longer remember the details of the protocol, but
my question here would be why not wait for the <features> text?

> But I found out that
> waiting a little (200ms+) before reading the socket gives ejabberd
> enough time to reply both <stream> and <features> in one shot, then
> making the next socket read return what is expected.
>
> I decided to modify the possible values for --starttls-proto option:
> xmpp is replaced with xmpp-client or xmpp-server to avoid confusion.

We would have to keep 'xmpp' for backwards compatibility (most likely
to the most common variant). The CANON_SERVICE() macro should be
updated as well.

> If you ask, I can make a merge request on gitlab too. But I'm not a C
> programmer and I'm sure my patch can be improved. Maybe there's a better
> solution than waiting 200ms for instance. Feel free to rewrite it as needed.

I'd really appreciate a merge request, ideally with a testsuite
similarly to tests/starttls-smtp.sh and friends.

regards,
Nikos