On 3/4/14, 11:11 AM, Thijs Alkemade wrote:
On 4 mrt. 2014, at 10:58, Dave Cridland <[email protected]
<mailto:[email protected]>> wrote:
On 4 March 2014 10:17, Thijs Alkemade <[email protected]
<mailto:[email protected]>> wrote:
On 3 mrt. 2014, at 22:35, Dave Cridland <[email protected]
<mailto:[email protected]>> wrote:
On 3 March 2014 21:47, Waqas Hussain <[email protected]
<mailto:[email protected]>> wrote:
On Mon, Mar 3, 2014 at 3:46 PM, Fedor Brunner
<[email protected] <mailto:[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 <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
