[Standards] Re: NEW: XEP-0474 (SASL SCRAM Downgrade Protection)
Am Samstag, dem 28.10.2023 um 14:40 +0100 schrieb Matthew Wild: > > So, SSDP "only" allows the client to detect the difference between > two cases: > > 1) The real server advertises new channel binding methods the client > does not understand > 2) An MITM is trying to trick the client into authenticating > > In both cases the client must abort the authentication. What's > gained? > No > Or are you saying that in case 1 the client should feel free to try a > SASL mechanism that does not do channel binding? Hi Matthew, Client is always free to use whatever method and mechanism it wants. SSDP just allows extending SASL SCRAM tampering protection to application layer. Meaning the client made mech/tls-binding selection while being fully aware of all available alternatives and nothing outside of the existing security context influenced that decision. And tampering protection is common for SASL SCRAM, tampered communication should result in failed authentication and hence no access to protected data (eg unencrypted communication). Regardless what exactly is being tampered with (ClientProof/ServerSignature mismatch). Regards, Ruslan signature.asc Description: This is a digitally signed message part ___ Standards mailing list -- standards@xmpp.org Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s ___
[Standards] Re: NEW: XEP-0474 (SASL SCRAM Downgrade Protection)
Hi Matthew,
the following is written under the premise that the client does not support
SASL PLAIN.
SSDP is a replacement for pinning, that solves two main shortcomings when
doing pinning (either for channel-binding types or for SASL mechanisms), while
still being at least as secure as pinning:
1) Pinning does not secure the very first connection.
2) When clients use pinning, server operators can not deactivate something
that's pinned by clients (for example due to bugs in the software,
configuration errors etc.)
Let me illustrate this with three (attack) scenarios:
A) The attacker is bit more sophisticated than they were in the recent attack
and was able to get the private key for the server's certificate and they are
only targeting a special user (or a small group of users). This user already
connected to the server and thus pinned tls-exporter and tls-unique channel
bindings to be supported by the server and thus refuses to downgrade to tls-
server-end-point (or to no channel-binding at all).
The attacker now tries to downgrade to tls-server-end-point and the client
will, thanks to pinning, detect this downgrade, alert the user and refuse to
connect.
No matter how scary the message is, most users will first of all think of a
bug, delete their account in the client and set it up again. Especially if
they ask friends that don't have this connection problems (and may even tell
them to reinstall the app).
After reinstalling the app and setting up their account again, everything
works as before and the client even shows channel-binding in use (if the user
even checks that), but in fact now the MITM attacker was successful and is
able to intercept or even manipulate every stanza sent/received on the user's
connection.
But if the client and server in this scenario supported SSDP, the MITM would
not have been successful, no matter how often the user tries to reconfigure/
reinstall their client. The attacker won't succeed in MITMing the connection
of that user. That's shortcoming 1) being fixed by SSDP.
B) In this scenario, we have a setup where either the client or server are not
able to do channel-binding. That may well be due to restrictions of the client
platform, for example a web based client using BOSH or Websockets (or [*] on
iOS), or the server software/tls implementation.
Now the server operator briefly activates a SASL method. Let's say they
activate SCRAM-SHA-512 and previously had a working setup that only advertised
and supported SCRAM-SHA-1. But after activating that, they become aware that
this setup has some bugs: some clients are able to authenticate using SCRAM-
SHA-512 and some don't but still try, resulting in errors yelled at those
users. That may be because the server software has bugs [**], maybe some
clients have bugs in their SCRAM-SHA-512 implementation (but not in their
SCRAM-SHA-1 implementation), or maybe the server operator simply made some
configuration errors they are not able to fix (quickly).
Just going back to the old known good configuration will solve these issues for
those clients not being able to properly use SCRAM-SHA-512, but since all
clients that *were* able to authenticate using SCRAM-SHA-512 now pinned that
one, disabling this new SASL method again, will make those clients not connect
anymore. That's more or less a DOS vector introduced by pinning.
If SSDP was used, the clients would not need to pin anything, because the SSDP
hash included in the SCRAM handshake will detect that this apparent downgrade
is in fact no real downgrade but only a legitimate server configuration change.
See [1] for a similar attack that involves a platform not supporting channel-
binding that's also mitigated by SSDP. More than that: web clients not being
able to permanently store any pinning information would still be ("stateless")
protected by SSDP.
C) A server is configured to use strong channel-binding (tls-exporter / tls-
unique) but since the server grew the server operator decides to do TLS
offloading and thus can only offer tls-server-end-point channel-binding (which
is
still way better than no channel-binding at all and even this channel-binding
type would have prevented the recent attack on xmpp.ru). Another reason to go
from tls-exporter / tls-unique to tls-server-end-point may well be a bug in
the server/tls library [**]. And a slight modification of this scenario would
be the server operator disabling channel-binding altogether (for the same
reasons).
But since clients are pinning channel-binding types, this configuration change,
albeit legitimate, will be erroneously detected as attack and clients won't
connect to the server anymore.
(By the way: the server operator now telling all users to resetup their
accounts is not only very inconvenient, it will create a unique opportunity
for a MITM attacker being able to get hold of the server's private key, too.)
If SSDP was used, the clients would have been able to
[Standards] Re: NEW: XEP-0474 (SASL SCRAM Downgrade Protection)
On Fri, 6 Jan 2023 at 16:42, Thilo Molitor wrote: > No matter how: now I can MITM the TLS connection, but channel-binding will > detect this and fail the authentication, maybe even inform the user. > To be able to read incoming and outgoing xmpp stanzas or even manipulate them, > I need to get rid of channel-binding. > I manipulate the channel-binding list the server is advertising to only list > dummy channel-bindings the client does not support. Now the client has two > choices: fall back to no channel-binding at all (I, the attacker, win) or > abort authentication. Aborting authentication may be bad, because protocol > agility might introduce new channel-binding mechanisms the client does not > know and a server might be configured to only support these. The client would > effectively DOS itself in this scenario. > Pinning the channel-binding method is of limited use, too (see my last mail) > and can also easily result in DOS. > That means, as a client developer, I have no good option at hand. > That's what SSDP is trying to solve by providing a mechanism to detect such > downgrades without all of the downsides of pinning which is only an incomplete > solution to this problem. So, SSDP "only" allows the client to detect the difference between two cases: 1) The real server advertises new channel binding methods the client does not understand 2) An MITM is trying to trick the client into authenticating In both cases the client must abort the authentication. What's gained? Or are you saying that in case 1 the client should feel free to try a SASL mechanism that does not do channel binding? Regards, Matthew ___ Standards mailing list -- standards@xmpp.org Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s ___
[Standards] Re: NEW: XEP-0474 (SASL SCRAM Downgrade Protection)
Remember me saying that TLS itself is not enough when discussing about SSDP and channel-binding in general ~9 month ago? Here [1] is a real world example of an xmpp mitm-attack where channel-binding and SSDP would have been helpful. For convenience: [2] shows the attack models SSDP mitigates. -tmolitor [1] https://notes.valdikss .org .ru /jabber.ru-mitm/ (note the spaces to counter spam filters) [2] https://xmpp.org/extensions/xep-0474.html#reqs Am Freitag, 6. Januar 2023, 17:40:55 CEST schrieb Thilo Molitor: > Hi Dave, > > > Not using PLAIN is insufficient - clients have to only use SCRAM, and in > > particular, variants of SCRAM that are considered secure. > > Not exactly true. One could design a channel-binding downgrade detection for > SASL-EXTERNAL using client certificates, too. > But I wanted to start with the most common SASL mechanisms used in the wild > by xmpp servers. And SSDP can be used for OPAQUE, too, just by defining the > exact same optional attribute for OPAQUE that SSDP is defining for SCRAM. > In fact I might update the XEP to define the same protection for OPAQUE, > too. > > So yes, if someone is deploying SCRAM-SHA256, this would detect a > > downgrade > > to SCRAM-SHA1, but only while SCRAM-SHA1 is proof against compromise. And > > while SCRAM-SHA1 *is* proof against compromise (modulo leaks of the server > > credential store), a downgrade to it isn't really something to worry about > > (and why is an attacker doing this?). I would therefore argue this > > provides > > no practical protection against downgrades of SASL mechanisms. > > You assume that "compromise" always means the attacker would be able to > break the SCRAM handshake in realtime to change the SSDP hash and make SSDP > useless. But SCRAM-SHA-1 could once well be broken in the sense that it > costs x days of computation time to break it and recover the password / > hash. > In such cases detecting the MITM and alerting the user would allow the user > to change the password and prevent the attack this way. > > > Therefore, this is *at best* protecting against changing the channel > > binding type to support only channel binding types that the client does > > not > > support, or are weak enough to be under the attacker's control. > > Well not exactly (see above), but well, as I said before: the main goal of > SSDP is to detect/prevent channel-binding downgrades. > > > Maybe it'd be better to start with a concrete example of an attack, > > demonstrate its utility to the attacker, and then show how this prevents > > the attack? > > I'm under the impression I constantly explain the same thing over and over > again, see [1] or even the Security section of XEP-0440 [2] for example. > But well, let's do it again... > > I'm a MITM attacker using either a stolen cert+key or I've managed to > somehow get a CA signed cert+key combination. > How I did this is out of scope here, maybe I hacked the mailserver and some > CA is still using domain validation via email, or the user installed the > corporate/school CA and now gets MITMed by his employer/school etc. > > No matter how: now I can MITM the TLS connection, but channel-binding will > detect this and fail the authentication, maybe even inform the user. > To be able to read incoming and outgoing xmpp stanzas or even manipulate > them, I need to get rid of channel-binding. > I manipulate the channel-binding list the server is advertising to only list > dummy channel-bindings the client does not support. Now the client has two > choices: fall back to no channel-binding at all (I, the attacker, win) or > abort authentication. Aborting authentication may be bad, because protocol > agility might introduce new channel-binding mechanisms the client does not > know and a server might be configured to only support these. The client > would effectively DOS itself in this scenario. > Pinning the channel-binding method is of limited use, too (see my last mail) > and can also easily result in DOS. > That means, as a client developer, I have no good option at hand. > That's what SSDP is trying to solve by providing a mechanism to detect such > downgrades without all of the downsides of pinning which is only an > incomplete solution to this problem. > > Please note: in the case of a stolen cert+key I can just downgrade from tls- > exporter to tls-server-end-point instead of downgrading from > channel-binding to no channel-binding. But other than that, the attack > above is still the same: Without SSDP I can MITM the connection without > server and client noticing it. > > -tmolitor > > [1] https://mail.jabber.org/pipermail/standards/2022-October/039025.html > [2] https://xmpp.org/extensions/xep-0440.html#security > > > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___
