5.2.20
09/25/2020

[#287] The login on a server with Debian Buster does not work
Summary The login on a server with Debian Buster does not work
Queue gloox
Queue Version 1.0.22
Type Bug
State Assigned
Priority 2. Medium
Owners js (at) camaya (dot) net
Requester stefan+xmpp (at) debxwoody (dot) de
Created 10/12/2019 (349 days ago)
Due
Updated 12/08/2019 (292 days ago)
Assigned 12/08/2019 (292 days ago)
Resolved

History
12/08/2019 07:29:51 PM Jakob Schröter Comment #10 Reply to this comment
This temporary fix is now in just-released 1.0.23.
12/08/2019 03:20:09 PM stefan+xmpp (at) debxwoody (dot) de Comment #9 Reply to this comment
I am now able to reproduce this.

So far I was able to link this to usage of TLS 1.3. If I forbid 1.3 
it works. Could you check whether it works for you with the attached 
patchlet? This is not the final solution, of course.
it's woring
12/08/2019 02:28:16 PM Jakob Schröter Comment #8
New Attachment: tls13.diff Download
State ⇒ Assigned
Reply to this comment
I am now able to reproduce this.

So far I was able to link this to usage of TLS 1.3. If I forbid 1.3 it 
works. Could you check whether it works for you with the attached 
patchlet? This is not the final solution, of course.
12/08/2019 07:33:51 AM stefan+xmpp (at) debxwoody (dot) de Comment #7 Reply to this comment
So far I can't reproduce this. Both gloox 1.0.22 and trunk work for me.
Client: Gnutls 3.3.30
Server: Prosody 0.10 nightly on Debian Buster
Just checked again. Still not able to connect:
I'm running Debian Debian on Server and Client.
GnuTLS: Version: 3.6.7-4

Witth ./configure --with-gnutls=no it is working well (OpenSSL).
I'm using a LE Cert.

12/07/2019 10:43:25 PM Jakob Schröter Comment #6 Reply to this comment
So far I can't reproduce this. Both gloox 1.0.22 and trunk work for me.
Client: Gnutls 3.3.30
Server: Prosody 0.10 nightly on Debian Buster
10/24/2019 06:23:28 PM stefan+xmpp (at) debxwoody (dot) de Comment #5 Reply to this comment
Workaround: ./configure --with-gnutls=no
10/12/2019 07:25:57 PM stefan+xmpp (at) debxwoody (dot) de Comment #4 Reply to this comment
log: level: 0, area: 8, connection encryption active
log: level: 0, area: 8, Sending xml string... SK
GnuTLSBase::encrypt: <?xml version='1.0' ?><stream:stream 
to='debxwoody.de' xmlns='jabber:client' 
xmlns:stream='http://etherx.jabber.org/streams'  xml:lang='en' 
version='1.0'>
GnuTLSBase::encrypt - gnutls_record_send
GnuTLSBase::encrypt done
log: level: 0, area: 262144, <?xml version='1.0' ?><stream:stream 
to='debxwoody.de' xmlns='jabber:client' 
xmlns:stream='http://etherx.jabber.org/streams'  xml:lang='en' 
version='1.0'>
log: level: 0, area: 8, Sending xml string...done SK
log: level: 2, area: 8, handleHandshakeResult() - Done
GnuTLSBase::handshake() true done
ConnectionTCPClient::recv Data: D6D700A0
ConnectionTCPClient::recv Data:
ConnectionTCPClient::recv timeout = -1
dataAvailable
ConnectionTCPClient::recv: 79 size
Calling handleReceivedData()
ClientBase::handleReceivedData
ClientBase::handleReceivedData - decrypt
GnuTLSBase::decrypt
GnuTLSBase:  gnutls_record_recv 17000
GnuTLSBase:decrypt() None data? -28
Fehler: Resource temporarily unavailable, try 
again.ConnectionTCPClient::recv Data: D6D6F170
ConnectionTCPClient::recv Data:
ConnectionTCPClient::recv timeout = -1
dataAvailable
ConnectionTCPClient::recv: 557 size
Calling handleReceivedData()
ClientBase::handleReceivedData
ClientBase::handleReceivedData - decrypt
GnuTLSBase::decrypt
GnuTLSBase:  gnutls_record_recv 17000
GnuTLSBase:decrypt() None data? -28
Fehler: Resource temporarily unavailable, try 
again.ConnectionTCPClient::recv Data: D6D7C640
ConnectionTCPClient::recv Data:
ConnectionTCPClient::recv timeout = -1


I changed the implementation:

       ret = static_cast<int>( gnutls_record_recv( *m_session, m_buf, 
m_bufsize ) );
       if(ret == GNUTLS_E_AGAIN) {
         ret = static_cast<int>( gnutls_record_recv( *m_session, 
m_buf, m_bufsize ) );
       }

I looks littel bit better:

<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>.....
Processing SASL challenge
...

GnuTLSBase:  gnutls_record_recv 17000
log: level: 0, area: 8, ClientBase::handleDecryptedData
ClientBase::parse
Parser::streamEvent
log: level: 0, area: 8, handleTag
log: level: 0, area: 131072, <failure 
xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><malformed-request/><text>Invalid 
channel binding value.</text></failure>
log: level: 0, area: 4, handleNormalNode
log: level: 0, area: 4, failure
log: level: 2, area: 4, SASL authentication failed!
log: level: 0, area: 8, Sending xml string... SK
GnuTLSBase::encrypt: </stream:stream>




10/12/2019 06:51:30 PM stefan+xmpp (at) debxwoody (dot) de Comment #3 Reply to this comment
With which XMPP server software does this happen?
prosody 0.11.2
10/12/2019 06:15:57 PM Jakob Schröter Comment #2 Reply to this comment
With which XMPP server software does this happen?
10/12/2019 05:16:42 AM stefan+xmpp (at) debxwoody (dot) de Comment #1
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Type ⇒ Bug
Summary ⇒ The login on a server with Debian Buster does not work
Queue ⇒ gloox
Reply to this comment
On a Debian stretch it is working, but not on Debian buster.

I'm not sure, but maybe there are changes in the TLS Version or 
implementation.

File: tlsgnutlsbase.cpp line 78 (int GnuTLSBase::decrypt( const 
std::string& data ) )
It seems on my env there is a return of GNUTLS_E_AGAIN, which is not 
handled correctly.