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: [email protected] > _______________________________________________ _______________________________________________ Standards mailing list -- [email protected] Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s _______________________________________________
