Re: [TLS] Verify data in the RI extension?
Michael D'Errico <mike-list@pobox.com> Sun, 29 November 2009 17:02 UTC
Return-Path: <mike-list@pobox.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 19D0D3A68C8 for <tls@core3.amsl.com>; Sun, 29 Nov 2009 09:02:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.514
X-Spam-Level:
X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599]
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 VOvc9xOxTRoI for <tls@core3.amsl.com>; Sun, 29 Nov 2009 09:02:01 -0800 (PST)
Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id D98E43A67FD for <tls@ietf.org>; Sun, 29 Nov 2009 09:01:59 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id B0D7EA2E46 for <tls@ietf.org>; Sun, 29 Nov 2009 12:01:52 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=7Qpt/+lsN1t8 HHs0rLlH7m/gaeU=; b=KNEL0Wj+53H+ToGgOj6Ume5pHWFoNc+eN0WDq9OZDXew qJUHh1jWjiynmPQmSv0UPTzO+/GydAR9Ra4ZUQYsrBLzkJ7oUZWAJOMw/YmI3RRB nPf+ogHqSMr+BLJPhq3zoFMQuY1EGuw25jMfRUy3dkSmYQ2HwoHpidW/kNKsqOQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=hGqQfX 5G3jT6UbUP7WmrCwKc5puFSlKGO1PyTS/Z2sIhstgyBDYYEW9Lf5fKIfAnJEnc0/ XljN7hHfc01FeBB+kl0bAnyrWItNtkIA9sJ0CSm0d41BvJzg/6OD6Pr1/gdXKVx5 p70hNQYzrhVB3xiw/RyYCFIylJL8S7G5fI/YM=
Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id AC0FEA2E45 for <tls@ietf.org>; Sun, 29 Nov 2009 12:01:52 -0500 (EST)
Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 20DFFA2E44 for <tls@ietf.org>; Sun, 29 Nov 2009 12:01:51 -0500 (EST)
Message-ID: <4B12A95E.6040402@pobox.com>
Date: Sun, 29 Nov 2009 09:03:26 -0800
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: tls@ietf.org
References: <9923D81D-BABA-4897-A0E3-6938FFB70045@checkpoint.com> <C7355261.6BB2%stefan@aaa-sec.com> <20091127151113.BDEF16C3795@kilo.networkresonance.com> <4B10E225.4010501@jacaranda.org> <4B117AF2.20703@pobox.com> <4B11C156.7060204@jacaranda.org> <4B11FBF8.8080400@pobox.com> <4B1205AC.3060106@jacaranda.org>
In-Reply-To: <4B1205AC.3060106@jacaranda.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: E440A948-DD08-11DE-849E-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com
Subject: Re: [TLS] Verify data in the RI extension?
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: Sun, 29 Nov 2009 17:02:02 -0000
David-Sarah Hopwood wrote: > Michael D'Errico wrote: >> David-Sarah Hopwood wrote: >>> Michael D'Errico wrote: >>>> David-Sarah Hopwood wrote: > [...] >>>>> That potential weakness can be avoided by encoding the data to be added >>>>> into the hash as follows: >>>>> >>>>> struct { >>>>> enum { fake_finished(20) } fake_handshake_type; >>>>> enum { zero(0), (2^24-1) } fake_length; >>>>> opaque previous_client_verify_data<12..255>; >>>>> opaque previous_server_verify_data<12..255>; >>>>> } PreviousVerifyData; >>>> I like the direction this is going, but think that using a length of >>>> zero doesn't quite patch the potential weakness. >>> It does: as I said, for an implementation to be vulnerable it would >>> have to violate two existing 'MUST's -- failing to abort the handshake >>> on an out-of-order handshake message, and failing to check the >>> correctness of the verify_data in a Finished message. If it gets the >>> latter wrong, then it's clearly insecure anyway. What is sent after >>> the fake Finished message doesn't matter for avoiding this weakness. >> The theoretical weakness, as I understand it, is that inserting the >> previous verify_data directly into the handshake message stream would >> allow an attacker to send the previous data to an unpatched peer at the >> point where it would get inserted by a patched peer. If (and it's a >> big if) that peer ignores that data, then the handshake has the possibility >> of completing. > > The problem was that it wasn't possible to infer from the spec that > any possible extra handshake message at that point would cause an abort. > For the Finished message, it is possible to infer that it will. > >> Your fix is to insert a "fake" header in front of the verify_data to make >> the attack impossible. The problem with using a zero length is that the >> 4-byte header you inserted is a _valid zero-length Finished message_. > > No, a valid Finished message would have to include a verify_data hash > (36 bytes in SSLv3; 12 bytes or more in TLS). It isn't plausible to > suppose that an implementation that is secure in other respects would > just ignore an extra Finished message of the wrong length and not > containing the right hash. I meant "well-formed", not valid, sorry. It is plausible to think that a peer might ignore an empty Finished message, if you believe it can be broken in the way that would allow the theoretical attack to succeed. Making the "fake_length" extend beyond the end of the PreviousVerifyData completely solves this since it would cause the peer to read parts of the subsequent valid messages into the fake Finished message. Thus the Certificate message would be lost, making it impossible for the handshake to succeed. And if that doesn't convince you, would you agree that changing the length wouldn't hurt anything? If so, then you can appease me by making it 0xFFFFFF instead of zero. Mike
- Re: [TLS] Verify data in the RI extension? Stefan Santesson
- [TLS] Avoiding first use of RI in ClientHello Eric Rescorla
- Re: [TLS] Avoiding first use of RI in ClientHello Stefan Santesson
- Re: [TLS] Avoiding first use of RI in ClientHello Dr Stephen Henson
- Re: [TLS] Avoiding first use of RI in ClientHello Robert Relyea
- Re: [TLS] Avoiding first use of RI in ClientHello Eric Rescorla
- Re: [TLS] Avoiding first use of RI in ClientHello Yngve N. Pettersen (Developer Opera Software ASA)
- Re: [TLS] Avoiding first use of RI in ClientHello peter.robinson
- Re: [TLS] Avoiding first use of RI in ClientHello Min Huang
- Re: [TLS] Verify data in the RI extension? Yoav Nir
- Re: [TLS] Avoiding first use of RI in ClientHello Pasi.Eronen
- Re: [TLS] Avoiding first use of RI in ClientHello Pasi.Eronen
- [TLS] Verify data in the RI extension? Stefan Santesson
- Re: [TLS] Verify data in the RI extension? Stefan Santesson
- Re: [TLS] Avoiding first use of RI in ClientHello Eric Rescorla
- [TLS] Perhaps there's another way. Was: Verify da… Marsh Ray
- Re: [TLS] Perhaps there's another way. Was: Verif… Dr Stephen Henson
- Re: [TLS] Avoiding first use of RI in ClientHello Stefan Santesson
- [TLS] What would be the point of removing signall… David-Sarah Hopwood
- Re: [TLS] Perhaps there's another way. Was: Verif… Marsh Ray
- Re: [TLS] Perhaps there's another way. Was: Verif… Dr Stephen Henson
- Re: [TLS] What would be the point of removing sig… Stefan Santesson
- Re: [TLS] What would be the point of removing sig… Marsh Ray
- Re: [TLS] What would be the point of removing sig… Bodo Moeller
- Re: [TLS] Perhaps there's another way. Was: Verif… Nelson B Bolyard
- Re: [TLS] What would be the point of removing sig… Nelson B Bolyard
- Re: [TLS] What would be the point of removing sig… Stefan Santesson
- Re: [TLS] Verify data in the RI extension? Pasi.Eronen
- Re: [TLS] Verify data in the RI extension? Simon Josefsson
- Re: [TLS] Verify data in the RI extension? Stefan Santesson
- Re: [TLS] Verify data in the RI extension? Pasi.Eronen
- Re: [TLS] Verify data in the RI extension? Pasi.Eronen
- Re: [TLS] Verify data in the RI extension? Martin Rex
- Re: [TLS] Verify data in the RI extension? Nikos Mavrogiannopoulos
- Re: [TLS] Verify data in the RI extension? Stefan Santesson
- Re: [TLS] Verify data in the RI extension? Eric Rescorla
- Re: [TLS] Verify data in the RI extension? Stefan Santesson
- Re: [TLS] Verify data in the RI extension? Eric Rescorla
- Re: [TLS] Verify data in the RI extension? Martin Rex
- Re: [TLS] Verify data in the RI extension? Eric Rescorla
- Re: [TLS] Verify data in the RI extension? Martin Rex
- Re: [TLS] Verify data in the RI extension? Martin Rex
- Re: [TLS] Verify data in the RI extension? Martin Rex
- Re: [TLS] Verify data in the RI extension? Stefan Santesson
- Re: [TLS] Verify data in the RI extension? Eric Rescorla
- Re: [TLS] Verify data in the RI extension? Eric Rescorla
- Re: [TLS] Verify data in the RI extension? Martin Rex
- Re: [TLS] Verify data in the RI extension? Eric Rescorla
- Re: [TLS] Verify data in the RI extension? Martin Rex
- Re: [TLS] Verify data in the RI extension? Martin Rex
- Re: [TLS] Verify data in the RI extension? Pasi.Eronen
- Re: [TLS] Verify data in the RI extension? Martin Rex
- Re: [TLS] Verify data in the RI extension? Eric Rescorla
- Re: [TLS] Verify data in the RI extension? Martin Rex
- Re: [TLS] Verify data in the RI extension? Pasi.Eronen
- Re: [TLS] Avoiding first use of RI in ClientHello Bodo Moeller
- Re: [TLS] Verify data in the RI extension? Bodo Moeller
- Re: [TLS] Verify data in the RI extension? Michael D'Errico
- Re: [TLS] What would be the point of removing sig… David-Sarah Hopwood
- Re: [TLS] What would be the point of removing sig… David-Sarah Hopwood
- Re: [TLS] What would be the point of removing sig… David-Sarah Hopwood
- Re: [TLS] Verify data in the RI extension? David-Sarah Hopwood
- Re: [TLS] Verify data in the RI extension? Michael D'Errico
- Re: [TLS] Verify data in the RI extension? David-Sarah Hopwood
- Re: [TLS] Verify data in the RI extension? Michael D'Errico
- Re: [TLS] Verify data in the RI extension? David-Sarah Hopwood
- Re: [TLS] Verify data in the RI extension? Bodo Moeller
- Re: [TLS] What would be the point of removing sig… Bodo Moeller
- Re: [TLS] Verify data in the RI extension? Michael D'Errico
- Re: [TLS] Verify data in the RI extension? Michael D'Errico
- Re: [TLS] Verify data in the RI extension? David-Sarah Hopwood
- Re: [TLS] Verify data in the RI extension? Marsh Ray
- Re: [TLS] Verify data in the RI extension? Stefan Santesson
- Re: [TLS] Verify data in the RI extension? Yoav Nir