What steps will reproduce the problem?
1. Configure authentication which supports SCRAM-*-PLUS
2. Connect with a client using TLSv1.3
What is the expected output?
SCRAM-*-PLUS should not be offered, since it cannot succeed on a TLSv1.3 connection.
What do you see instead?
What version of the product are you using? On what operating system?
diebesban.de is running Prosody version trunk nightly build 1268 (2020-05-02, b81f4fd7f21a) on Linux
Please provide any additional information below.
This is the stream header sent by the server:
<stream:stream xmlns='jabber:client' from='diebesban.de' id='257a40b1-fbc0-417e-8009-ae28076e8236' xmlns:stream='http://etherx.jabber.org/streams' version='1.0' xml:lang='en'>
My client is claiming to have negotiated TLS with version code 0x304, which according to my research is TLSv1.3
tls-unique as required for SCRAM-*-PLUS is undefined with TLSv1.3 and cannot be used.
This will likely also be the case if TLS 1.2 or earlier is used and the connection has been renegotiated (in which case TLS unique channel binding data isn't unique enough to actually establish a channel binding and it shouldn't be offered by the underlying TLS implementation).
This is what I see on the server side (info log level):
May 03 13:52:14 c2s55f314345a90 info Client connected
May 03 13:52:14 c2s55f314345a90 info Stream encrypted (TLSv1.3 with TLS_AES_256_GCM_SHA384)
May 03 13:52:14 c2s55f314345a90 info Authenticated as email@example.com
May 03 13:52:15 c2s55f314345a90 info Client disconnected: connection closed
OpenSSL and LuaSec happily reports the finished blob on TLS 1.3, so the only way for Prosody to detect this is by checking the TLS version, which is not great.
The optimal solution IMO would be to have an API in LuaSec and/or OpenSSL that reports what channel binding methods can be used, and their respective blobs.
Reported a feature request to OpenSSL: