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 distinguish that
legitimate configuration change from an attack and not drop the connection.
Now, with these scenarios (A, B, C) and improvements over pinning (1, 2) in
mind, let's answer your specific questions:
> 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
No, SSDP is capable of doing more.
> 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?
Yes and no, that depends on the concrete scenario and thread model, I guess.
Maybe the client could even ask the user (remember: SSDP will make sure that
the server not advertising any channel-binding type usable by the client is
not due to an attacker doing a downgrade).
Regards,
Thilo (and Friedrich)
[*] Up to today I was not able to figure out how to implement tls-unique
channel-binding using Apple's network framework. So channel-binding in TLSv1.2
is not supported in Monal (yet), tls-exporter is, though.
[**] Those bugs may persist for a very long time. Debian Bullseye, for
example, still has a prosody-modules package from 2021-01-30 that does not
include this push module fix: https://hg.prosody.im/prosody-modules/rev/
157fa4e535b0
And up to today we still see *many* servers still using that old and broken
module for sending pushes to our Monal pushservers.
[1] https://xmpp.org/extensions/xep-0474.html#sect-idm45721839708464
Am Samstag, 28. Oktober 2023, 15:40:09 CET schrieb Matthew Wild:
> On Fri, 6 Jan 2023 at 16:42, Thilo Molitor <[email protected]> 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 -- [email protected]
> Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
> _______________________________________________
_______________________________________________
Standards mailing list -- [email protected]
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
_______________________________________________
