Re: [TLS] TLS or HTTP issue?

Dean Anderson <> Fri, 06 November 2009 22:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 341B43A67FA for <>; Fri, 6 Nov 2009 14:29:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LV6RbX4t5+SV for <>; Fri, 6 Nov 2009 14:29:13 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1E6AB3A67AD for <>; Fri, 6 Nov 2009 14:29:13 -0800 (PST)
Received: from ( []) (authenticated bits=0) by (8.12.11/8.12.11) with ESMTP id nA6MTNGm006860 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 6 Nov 2009 17:29:24 -0500
Date: Fri, 6 Nov 2009 17:29:23 -0500 (EST)
From: Dean Anderson <>
To: Florian Weimer <>
In-Reply-To: <>
Message-ID: <>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: Eric Rescorla <>, "" <>
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: Fri, 06 Nov 2009 22:29:14 -0000

On Fri, 6 Nov 2009, Florian Weimer wrote:

> * Nikos Mavrogiannopoulos:
> > I'll become a bit pedantic and note here that this isn't really a TLS
> > issue.

Its a TLS issue.  However I don't think we should worry too much about
https.  I've used client certificates on some websites, and let me tell
you, its really a non-starter to use renegotation because most
webservers have a 250k buffer (On apache this is a compile-time
constant) for renegotiation, which isn't big enough to complete a lot of
http transactions, anyway. As a result, one usually winds up breaking up
websites into two or more sites, with one site completely client
certificate controlled so that no renegotation necessary on that site,
and the rest of the content is on another site that also needs no

> Theoretically, this attack can be detected by the server,

Theoretically, I think not. The problem (inherent to every MITM attack)
is that there is some plaintext the MITM can change or otherwise use.  
The solution is the same in every case: Eliminate the plaintext or
encrypt it in a (e.g public key) cipher so that the MITM can't alter or
read it.

That's what should happen here. We should not worry about whether this
is hard to program or not.  It simply shouldn't be plaintext.  I don't
think it ought to be too difficult to program, as the client and server
have already public exchanged keys that could be used to encrypt the

Of course, https is still as screwed as before, but like I said above,
it is of no consequence as there are already problems with renegotation
that cause renegotiation to be avoided. So we need not worry about
https.  But renegotiation should be made to work in TLS, as other
protocols that rely on TLS don't have the large, essentially unlimited
transaction size problems that https has.


Av8 Internet   Prepared to pay a premium for better service?         faster, more reliable, better service
617 256 5494