On 4 mrt. 2014, at 10:58, Dave Cridland <[email protected]> wrote: > > > > On 4 March 2014 10:17, Thijs Alkemade <[email protected]> wrote: > > On 3 mrt. 2014, at 22:35, Dave Cridland <[email protected]> wrote: > >> >> >> >> On 3 March 2014 21:47, Waqas Hussain <[email protected]> wrote: >> On Mon, Mar 3, 2014 at 3:46 PM, Fedor Brunner <[email protected]> wrote: >> > -----BEGIN PGP SIGNED MESSAGE----- >> > Hash: SHA512 >> > >> > >> > Hi all, >> > this attack on TLS security may be interesting for XMPP >> > https://www.imperialviolet.org/2014/03/03/triplehandshake.html >> > https://secure-resumption.com/#further >> > >> > The attacker could modify tls-unique channel binding and affect >> > SCRAM-SHA-1-PLUS authentication method. >> > >> >> >> Yes, it's interesting, at a first glance. >> >> It would, however, only affect clients that do not verify certificates >> properly (at least at the point of sending SASL stuff). >> >> You also need clients and servers that are perfectly happy to see >> renegotiation, and it's not vastly obvious why XMPP *needs* any >> renegotiation. >> >> So something to be aware of, rather than panic over. >> >> Dave. > > > I disagree, there are good reasons to allow renegotiation on XMPP (for > example: hiding client-side certificates). > > > I'm willing to go along with that; however any client that was doing > strong-auth and taking the opportunity to hide their certificate would > probably check the server's cert.
Not checking certificates isn’t necessary for this attack. Suppose a s2s scenario with servers S1, S2 and S3. S1 connects to S2, S2 pretends to S1 that everything is OK and presents its valid and trusted certificate for S2.com and asks S1 for their client-side cert. But S2 is evil, does the resumption stuff described and thereby 'steals' S1’s client-side certificate and uses it to authenticate as S1 to S3. > Resumption, on the other hand, I don’t see quite as useful for XMPP, due to > StartTLS. Resumption is vital to this attack. > > > I don't understand why resumption wouldn't be as useful. Hm. Let me rephrase: resumption isn’t as helpful for XMPP as for HTTPS, as connections are typically much longer lived. Resumption is also a bit more tricky to implement due to StartTLS. > > From my very limited testing with a handful of servers and `openssl > s_client`, it seems most servers allow renegotiation. Servers running > Prosody/ejabberd did not allow resumption, but jabber.org (M-Link) does. > However, it seems the XMPP layer is treating any resumption as if it were a > new connection. > > > Yes, it should do. > > Resuming a TLS session and resuming the application session is something that > was discussed by (I think) a Nokia paper (Pasi Eironen, from memory). It > requires a substantial amount of support. > > Resuming a TLS session and enabling this to be used for authentication (due > to a previous application-layer authentication) was discussed in an I-D I did > years ago. Okay, good to know. Best regards, Thijs
signature.asc
Description: Message signed with OpenPGP using GPGMail
