On Fri, 6 Jan 2023 at 16:42, Thilo Molitor <th...@eightysoft.de> 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 _______________________________________________
