[Security] TLS Triple Handshakes

Thijs Alkemade me at thijsalkema.de
Tue Mar 4 11:11:53 UTC 2014


On 4 mrt. 2014, at 10:58, Dave Cridland <dave at cridland.net> wrote:

> 
> 
> 
> On 4 March 2014 10:17, Thijs Alkemade <me at thijsalkema.de> wrote:
> 
> On 3 mrt. 2014, at 22:35, Dave Cridland <dave at cridland.net> wrote:
> 
>> 
>> 
>> 
>> On 3 March 2014 21:47, Waqas Hussain <waqas20 at gmail.com> wrote:
>> On Mon, Mar 3, 2014 at 3:46 PM, Fedor Brunner <fedor.brunner at azet.sk> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/security/attachments/20140304/2b39f26e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.jabber.org/pipermail/security/attachments/20140304/2b39f26e/attachment.sig>


More information about the Security mailing list