[xmpp] [Fwd: Re: [TLS] TLS or HTTP issue?]

[Peter Saint-Andre <stpeter at stpeter.im>]

FYI from the TLS list.

-------- Original Message --------
Subject: Re: [TLS] TLS or HTTP issue?
Date: Wed, 11 Nov 2009 15:34:49 -0800
From: Chris Newman <Chris.Newman at Sun.COM>
To: Peter Saint-Andre <stpeter at stpeter.im>,        Nikos
Mavrogiannopoulos <nmav at gnutls.org>
CC: Eric Rescorla <ekr at rtfm.com>, tls at ietf.org
References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3 at rtfm.com>
<4AF33D07.7040100 at gnutls.org> <4AF455DF.5040106 at stpeter.im>

It is likely XMPP is vulnerable.  IMAP and SMTP are vulnerable.  The only
application protocol I've studied that I believe resists the vulnerability
is POP3+STLS (even pops may be vulnerable).

I know of two ways to leverage the TLS re-negotiation vulnerability to
attack applications:

1. Authenticating an otherwise un-trusted directive using credentials from
an authorized user.  As far as I know this attack only applies to HTTP-like
protocols (including IPP, SIP, HTTP, WebDAV, CalDAV, etc.) due to the poor
design of HTTP authentication, cookie and client certificate mechanisms.
Application protocols like IMAP, POP, SMTP, XMPP, BEEP with cleanly
separate not-authenticated and authenticated states are immune to this
attack.

2. Having one authorized and authenticated TLS session decrypt data from a
different TLS session.  This attack is most severe for SMTP+STARTTLS+BDAT
(since SMTP relays typically treat all senders as authenticated as long as
the recipient is in the local domain), but impacts most application
protocols that have a command to "send", "post", "put", "set an attribute"
or perform any write operation that can subsequently be read back.  In the
case of IMAP, this can be used by one authorized IMAP user (someone with an
account on the IMAP server) to potentially steal the login password of
another IMAP user on the same server (with some IMAP client behavior
caveats).

It is likely that XMPP is vulnerable to attack #2.

I would recommend anyone running an SMTP relay (port 25) to turn off both
the STARTTLS and SMTP AUTH features immediately until this is resolved.  An
SMTP Submission server (port 587, RFC 4409, requires SMTP AUTH to submit
mail) should keep STARTTLS enabled.  Sites that have not made the split
between SMTP relay and SMTP submission should do so -- they have different
security properties and this is yet another reason they should be different
services (either on different ports or different IP addresses).

		- Chris

--On November 6, 2009 9:59:11 -0700 Peter Saint-Andre <stpeter at stpeter.im>
wrote:

> On 11/5/09 2:00 PM, Nikos Mavrogiannopoulos wrote:
>> Eric Rescorla wrote:
>>> TLS WG members will want to check out this announcement of a
>>> new attack on the TLS renegotiation logic. See here:
>>>
>>> http://www.extendedsubset.com/
>>>
>>> The high-level summary is that the attacker negotiates TLS with the
>>> server and then subsequently proxies the client's negotiation *over*
>>> that channel. This allows the attacker to inject arbitrary content of
>>> their choice in front of data sent from the TLS client to the TLS
>>> server. This data will be treated by the server as if it came from the
>>> client. Once the new handshake has finished, the attacker can't
>>> do anything else useful.
> 
>>  I'll become a bit pedantic and note here that this isn't really a TLS
>> issue. We have an initial server-authenticated only session and some
>> renegotiation of parameters over it to authenticate the client. However
>> TLS doesn't guarantee[0] that if the renegotiation is successful
>> authenticating the client, then the data from the initial session were
>> also by the same authenticated client.
>>  Think for example a session that it is anonymous (DH). Why one should
>> assume that commands over the anonymous connection are to be trusted if
>> a successful renegotiation follows?
> 
>> So for me the issue is on HTTP's usage of the TLS protocol
>> renegotiation. After a TLS renegotiation for authentication the previous
>> command cache should have been cleared and reissued after negotiation.
> 
> I tend to agree. Some folks in the XMPP community have analyzed the use
> of TLS in XMPP, and their preliminary conclusion is that XMPP is not
> vulnerable to this attack because the client and server are required to
> clear the security context and restart the XML stream after TLS
> negotiation (or renegotiation). Those who did this analysis will publish
> a brief report about their findings in the near future.
> 
> Peter
>

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature