Re: [TLS] TLS or HTTP issue?
Chris Newman <Chris.Newman@Sun.COM> Wed, 11 November 2009 23:34 UTC
Return-Path: <Chris.Newman@Sun.COM>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1C843A6B64 for <tls@core3.amsl.com>; Wed, 11 Nov 2009 15:34:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.046
X-Spam-Level:
X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ad7fGzxiisl0 for <tls@core3.amsl.com>; Wed, 11 Nov 2009 15:34:24 -0800 (PST)
Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by core3.amsl.com (Postfix) with ESMTP id E3FFE3A699F for <tls@ietf.org>; Wed, 11 Nov 2009 15:34:23 -0800 (PST)
Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nABNYqR3014784 for <tls@ietf.org>; Wed, 11 Nov 2009 15:34:52 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-disposition: inline
Content-type: text/plain; CHARSET="US-ASCII"; format="flowed"
Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSY00100X8NGU00@fe-sfbay-09.sun.com> for tls@ietf.org; Wed, 11 Nov 2009 15:34:52 -0800 (PST)
Received: from [10.0.1.3] ([unknown] [10.1.110.5]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSY00FUFXI1QJ10@fe-sfbay-09.sun.com>; Wed, 11 Nov 2009 15:34:51 -0800 (PST)
Date: Wed, 11 Nov 2009 15:34:49 -0800
From: Chris Newman <Chris.Newman@Sun.COM>
In-reply-to: <4AF455DF.5040106@stpeter.im>
Sender: Chris.Newman@Sun.COM
To: Peter Saint-Andre <stpeter@stpeter.im>, Nikos Mavrogiannopoulos <nmav@gnutls.org>
Message-id: <57839EF28A3534D8E0C69AD4@446E7922C82D299DB29D899F>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <4AF33D07.7040100@gnutls.org> <4AF455DF.5040106@stpeter.im>
Cc: Eric Rescorla <ekr@rtfm.com>, tls@ietf.org
Subject: Re: [TLS] TLS or HTTP issue?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Nov 2009 23:34:25 -0000
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@stpeter.im> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 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 > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkr0Vd8ACgkQNL8k5A2w/vyeqQCgpzZakXwr62UdxAHdNyqwe4xe > WEUAoMPGdY94w+/+oAv9oYC0I9iu7hnI > =sjVM > -----END PGP SIGNATURE----- > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
- [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Marsh Ray
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Marsh Ray
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Florian Weimer
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Michael D'Errico
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Florian Weimer
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- [TLS] TLS or HTTP issue? (was: TLS renegotiation … Nikos Mavrogiannopoulos
- Re: [TLS] TLS renegotiation issue Yngve N. Pettersen (Developer Opera Software ASA)
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Marsh Ray
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Cullen Jennings
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Michael Gray
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS or HTTP issue? Florian Weimer
- Re: [TLS] TLS or HTTP issue? Bruno Harbulot
- Re: [TLS] TLS renegotiation issue Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] TLS or HTTP issue? Peter Saint-Andre
- Re: [TLS] TLS or HTTP issue? Martin Rex
- Re: [TLS] TLS or HTTP issue? (was: TLS renegotiat… Nicolas Williams
- Re: [TLS] TLS or HTTP issue? (was: TLS renegotiat… Nathaniel W Filardo
- Re: [TLS] TLS or HTTP issue? Marsh Ray
- Re: [TLS] TLS or HTTP issue? (was: TLS renegotiat… Nicolas Williams
- [TLS] draft-rescorla-tls-renegotiate.txt Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Michael D'Errico
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Marsh Ray
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Robert Relyea
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Michael D'Errico
- Re: [TLS] TLS or HTTP issue? Dean Anderson
- Re: [TLS] TLS renegotiation issue David Harrington
- [TLS] To API or not (Re: TLS renegotiation issue) Nicolas Williams
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Marsh Ray
- [TLS] Simple way to drop re-negotiation in HTTP (… Nicolas Williams
- Re: [TLS] TLS renegotiation issue Michael D'Errico
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Martin Rex
- Re: [TLS] Simple way to drop re-negotiation in HT… Marsh Ray
- Re: [TLS] TLS or HTTP issue? Nikos Mavrogiannopoulos
- Re: [TLS] TLS or HTTP issue? Marsh Ray
- Re: [TLS] TLS renegotiation issue Michael D'Errico
- Re: [TLS] TLS renegotiation issue Marsh Ray
- Re: [TLS] TLS or HTTP issue? Michael D'Errico
- Re: [TLS] Test Server (was TLS renegotiation issu… Michael D'Errico
- Re: [TLS] Test Server (was TLS renegotiation issu… Michael D'Errico
- Re: [TLS] TLS renegotiation issue Nagendra Modadugu
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS or HTTP issue? Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS or HTTP issue? Florian Weimer
- Re: [TLS] Simple way to drop re-negotiation in HT… Nicolas Williams
- Re: [TLS] TLS or HTTP issue? Chris Newman
- Re: [TLS] TLS or HTTP issue? (was: TLS renegotiat… Chris Newman
- Re: [TLS] TLS renegotiation issue Bodo Moeller
- Re: [TLS] TLS or HTTP issue? Nikos Mavrogiannopoulos
- [TLS] Comments on draft-rescorla-tls-renegotiate Nicolas Williams
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… Martin Rex
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… David-Sarah Hopwood
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… David-Sarah Hopwood
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… David-Sarah Hopwood
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… Nicolas Williams
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… Nicolas Williams
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… Nicolas Williams
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… Nelson B Bolyard
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… David-Sarah Hopwood
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… David-Sarah Hopwood
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… Bodo Moeller