Re: [TLS] TLS or HTTP issue?

Michael D'Errico <> Sat, 07 November 2009 17:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 893EB3A68AF for <>; Sat, 7 Nov 2009 09:51:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.587
X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mtDxuDquPnQT for <>; Sat, 7 Nov 2009 09:51:28 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8D37D3A688D for <>; Sat, 7 Nov 2009 09:51:28 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTP id BF0DF77851 for <>; Sat, 7 Nov 2009 12:51:52 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=rePPLpZrzBBV JirdNxLreYcRArU=; b=GnkqHsvPL/mdv9X1oG3SdnOrYvcXmPlvIAedxMOXKmju 2z/5kYXIfsEVnpAfGSykm9UdooWdNboGcAeEaSiBaDknedyWX/hqPRXq+zwT3woH iYpazjOnWF8Q5vQF8uH5Pmv8wmmwDnDj8tTWXTH+gh+qn5vLmyxz2afCcckuNdU=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=vYh25T fi6wY7BRIrtODHHgV/OohsulD2rQFjYW+HFGMZaUWY5n5LTkwekzZ5gfePAAbngN p+8/DMepvxFtKla0+2A9Jla9ObzHM7hWAkIA8ScSYysZ/K/jQD7wFqn7okx1x2GF 3bjmn/I8lcnfFh1es4DH3Rw3ql/3EGWEgPdUM=
Received: from a-pb-sasl-quonix. (unknown []) by (Postfix) with ESMTP id BBB7977850 for <>; Sat, 7 Nov 2009 12:51:52 -0500 (EST)
Received: from administrators-macbook-pro.local (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 44FB27784E for <>; Sat, 7 Nov 2009 12:51:52 -0500 (EST)
Message-ID: <>
Date: Sat, 07 Nov 2009 09:52:47 -0800
From: Michael D'Errico <>
User-Agent: Thunderbird (Macintosh/20090812)
MIME-Version: 1.0
To: "" <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 3B59E626-CBC6-11DE-B52F-7C40EE7EF46B-38729857!
Subject: Re: [TLS] TLS or HTTP issue?
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 07 Nov 2009 17:51:29 -0000

Marsh Ray wrote:
> Nikos Mavrogiannopoulos wrote:
>> the application layer
>> cannot distinguish between the two sessions (one before renegotiation,
>> one after). The problem was for me that you could receive any amount of
>> application data even after a rehandshake was requested, thus I had to
>> cache them and present to the application after rehandshake was finished.
> Yes, yes!
> The buffered stream IO model we all take for granted is insufficient to
> represent the semantics of a TLS connection in the presence of
> renegotiation!

My server works a bit differently; it does what I'll call "lazy
renegotiation."  If it receives a ClientHello for a renegotiation, it
calculates all of the response handshake messages and puts them into
the outbound queue for delivery to the client.  It will happily continue
sending application data to the client and also receiving and passing
application data back to the application while the pending TLS session
is in this uncompleted state.  I believe this is what the TLS spec

If the client continues with the handshake, those messages are processed
as they are received, and the pending TLS session moves closer to
completion.  It is possible for the client and/or server to end up with
two different active sessions -- one based on the renegotiation, and one
based on the original handshake.  This would happen if one side fails to
send a ChangeCipherSpec and Finished message.

So the question becomes: should this be a legal state to be in?  I could
add some logic to disallow the sending of application data over a newly-
installed renegotiated session until the peer has completed its side of
the handshake.  But it should probably be allowed to continue receiving
application data over the old session since it could have been in transit
prior to sending the Finished message.

I think a good addition to my API would be to have a callback that tells
the application when a renegotiation has completed, and to also pass back
any application data that was received under the old session, but not yet
read by the application.

There is another weird possibility that should probably be prohibited:
if for some reason a ChangeCipherSpec is received during a renegotiation,
but not followed immediately by a Finished message, the receipt of any
application data should cause a handshake failure.


> Even with an added callback for cert validation, ambiguities linger!
> I think it highly probable that real vulnerabilities exist in
> applications due to this mismatch.
> The draft-rescorla-tls-renegotiate extension should help quite a bit though.
> - Marsh