[Security] TLS Triple Handshakes

Peter Saint-Andre stpeter at stpeter.im
Tue Mar 4 11:30:35 UTC 2014


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

Typically, yes. But we also know that XMPP connections are not always as 
long-lived as we hope they might be (intermittent connectivity, sessions 
over BOSH or WebSocket, etc.). So resumption can still be helpful.

> 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 <http://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.

That would be:

http://tools.ietf.org/id/draft-cridland-sasl-tls-sessions-00.txt




More information about the Security mailing list