On 15 okt. 2014, at 10:57, Matthew Wild <[email protected]> wrote: > On 15 October 2014 08:47, Jonas Wielicki <[email protected]> wrote: > I’m not confident that this attack is (like BEAST and CRIME) relevant > for XMPP. > > It requires that the attacker is able to induce several SSL connections, > with the offset of the data to be attacked (which must be the same for > all attempts) and the size of the packet under the attackers precise > control. > > I can only think this would apply to s2s connections, if you had an account > on the server. As an active attacker you could break an s2s connection and > send a new stanza to re-establish. The stanza is under your control. Whether > this constitutes "precise control" I don't know. > > I don’t know of a scenario in XMPP C2S, nor can I imagine one for XMPP > S2S, where this would be plausibly possible. So I think it is not > relevant for XMPP (also, the usual opportunistic encryption argument for > s2s applies). > > Also, do XMPP S2S connections the “downgrade dance” mentioned in the paper? > > I know of no XMPP implementations that do this. So basically it would work > only if SSLv3 is the only protocol supported by one of the parties (I don't > think I've seen any servers that only support SSLv3).
There are about 199 SSLv3 only servers seen by xmpp.net: https://xmpp.net/reports.php#sslv3butnottls1 (though many test results on that list are more than a couple of weeks old, and I wouldn’t trust those too much) IIRC, the last time this was brought up someone mentioned that tkabber only recently started supporting TLS 1.0. That's the only client I can think of that only supported SSLv3. http://tkabber.jabber.ru/tkabber-1.0 mentions "Disabled SSLv2 and enabled TLSv1 TLS options"... that’s from january 1st this year. Regards, Thijs
signature.asc
Description: Message signed with OpenPGP using GPGMail
