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?
SCRAM-SHA-1-PLUS offered.
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:
<?xml version='1.0'?>
<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'>
<stream:features>
<register xmlns='urn:xmpp:invite'/>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>SCRAM-SHA-1-PLUS</mechanism>
<mechanism>SCRAM-SHA-1</mechanism>
<mechanism>PLAIN</mechanism>
</mechanisms>
<register xmlns='http://jabber.org/features/iq-register'/>
</stream:features>
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.
Sam Whited
on
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 observer-ping@diebesban.de
May 03 13:52:15 c2s55f314345a90 info Client disconnected: connection closed
Zash
on
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:
https://github.com/openssl/openssl/issues/12221
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? SCRAM-SHA-1-PLUS offered. 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: <?xml version='1.0'?> <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'> <stream:features> <register xmlns='urn:xmpp:invite'/> <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <mechanism>SCRAM-SHA-1-PLUS</mechanism> <mechanism>SCRAM-SHA-1</mechanism> <mechanism>PLAIN</mechanism> </mechanisms> <register xmlns='http://jabber.org/features/iq-register'/> </stream:features> 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).
How is it undefined? https://tools.ietf.org/html/rfc5929#section-3 https://tools.ietf.org/html/rfc8446#section-4.4.4
ChangesSee https://tools.ietf.org/html/rfc8446#appendix-C.5
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 observer-ping@diebesban.de 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: https://github.com/openssl/openssl/issues/12221
Changeshttps://hg.prosody.im/0.11/rev/1bfd238e05ad RIP SCRAM-PLUS
ChangesTLS 1.3 Binding here: - https://tools.ietf.org/html/draft-ietf-kitten-tls-channel-bindings-for-tls13
Good news, it is official: RFC 9266: Channel Bindings for TLS 1.3: - https://datatracker.ietf.org/doc/html/rfc9266 Thanks Sam for this work and Zash too. Details: - tls-unique for TLS =< 1.2 - tls-exporter for TLS = 1.3 Linked to: - https://issues.prosody.im/1760