Re: [TLS] Simple way to drop re-negotiation in HTTP (Re: draft-rescorla-tls-renegotiate.txt)

Marsh Ray <> Sat, 07 November 2009 06:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CAFB93A6881 for <>; Fri, 6 Nov 2009 22:00:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.303
X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DGnNDnOEKPnG for <>; Fri, 6 Nov 2009 22:00:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D0C783A6939 for <>; Fri, 6 Nov 2009 22:00:07 -0800 (PST)
Received: from ([]) by with esmtpa (Exim 4.68) (envelope-from <>) id 1N6eLf-000Cjr-1f for; Sat, 07 Nov 2009 06:00:31 +0000
Received: from [] (localhost []) by (Postfix) with ESMTP id 011EC667B for <>; Sat, 7 Nov 2009 06:00:29 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX18j0AJ/uNzR8KVFXTQLDqpS8pWq4B0r7dA=
Message-ID: <>
Date: Sat, 07 Nov 2009 00:00:29 -0600
From: Marsh Ray <>
User-Agent: Thunderbird (Windows/20090812)
MIME-Version: 1.0
To: "" <>
References: <> <4AF497C5.5060801@REDHAT.COM> <> <> <20091106234757.GN1105@Sun.COM>
In-Reply-To: <20091106234757.GN1105@Sun.COM>
X-Enigmail-Version: 0.96.0
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Simple way to drop re-negotiation in HTTP (Re: draft-rescorla-tls-renegotiate.txt)
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 06:00:09 -0000

Nicolas Williams wrote:
> The simplest way to drop re-negotiation in web servers is this (based on
> an idea by Nelson Bolyard):
>  - start two instances of the web server, one on an alternate port
>    number, with the same contents
>  - the primary instance will accept TLS user authentication, but will
>    not require it
>  - the instance on the alternate port will always require TLS user
>    authentication
>  - neither instance accepts TLS re-negotiations
>  - whenever the primary instance of the web server would request user
>    authentication via TLS do this instead: re-direct to client to the
>    same resource on the alternate port.
> That's almost entirely automatic.

> The only thing a webmaster must do is
> pick a suitable port number for the instance that requires user
> authentication.

Wow that does make it sound easy. All we need to do for HTTPS is get a
new port number assigned and the entire burden of the solution passes
from the TLS specs to server implementors and site admins?

Think of what this is proposing: all sites that currently depend on
renegotiation have to adjust their configuration. They have to
reconfigure their server's internal filters to allow the port. They have
to reconfigure their border firewalls to allow the new port. Every web
proxy device has to be reconfigured to support the new port. Web
applications that check for that magic number 443 will need to be
updated. We'll ignore reverse proxies and SSL offload for now.

Say only 5% of sites depend on renegotiation. OK, only 5% admins need to
reconfigure. Well, how well-tested is everything outside of those
admins' networks going to be? How well does the 5% case tend to work

Every client-side filter that watches outbound connections has to know
what that new port is being used for. Non-browser client code has to be
reviewed and possibly rewritten because it doesn't necessarily follow
HTTP redirects. Same-origin policies for cookies have to be checked for
how they handle the redirect to the new port.

Suppose that some ecommerce retailer is sending free smart-cards and usb
readers to 500K of their best customers this year (I got one in the mail
a few years ago). These cards web-enabled! (I.e. they present client
certs under the hood.) Armies of young, energetic support people will
spend the best years of their careers explaining to end users how to
reconfigure their ZoneAlarm.

>  - neither instance accepts TLS re-negotiations

Oh yes, even with all still need to update every web server
and client and TLS stack in the world!

> The redirects [] can be avoided somewhat
> by re-writing URLs in contents served to point to the right server
> instance.

Oh my.

- Marsh