#1542 SCRAM-*-PLUS offered even on TLSv1.3

Reporter Jonas Schäfer
Owner Zash
Stars ★★ (2)
  • Status-Fixed
  • Priority-Medium
  • Type-Defect
  • Milestone-0.11
  1. Jonas Schäfer on

    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.

  2. 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).

  3. Zash on

    How is it undefined? https://tools.ietf.org/html/rfc5929#section-3 https://tools.ietf.org/html/rfc8446#section-4.4.4

    • tags Status-NeedInfo
  4. Sam Whited on

    See https://tools.ietf.org/html/rfc8446#appendix-C.5

  5. Martin on

    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

  6. 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

    • tags Status-Blocked
  7. Zash on

    • tags Milestone-0.11 Status-Started
  8. Zash on

    https://hg.prosody.im/0.11/rev/1bfd238e05ad RIP SCRAM-PLUS

    • tags Status-Fixed
    • owner Zash
  9. Neustradamus on

    TLS 1.3 Binding here: - https://tools.ietf.org/html/draft-ietf-kitten-tls-channel-bindings-for-tls13

  10. Neustradamus on

    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

New comment

Not published. Used for spam prevention and optional update notifications.