Re: [TLS] draft-rescorla-tls-renegotiate.txt

Martin Rex <> Sat, 07 November 2009 01:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 90ECD3A67F3 for <>; Fri, 6 Nov 2009 17:00:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.128
X-Spam-Status: No, score=-6.128 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rjyGSBOymdss for <>; Fri, 6 Nov 2009 17:00:26 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 96AA93A67A8 for <>; Fri, 6 Nov 2009 17:00:26 -0800 (PST)
Received: from by (26) with ESMTP id nA710kHA001934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Nov 2009 02:00:46 +0100 (MET)
From: Martin Rex <>
Message-Id: <>
To: (Nelson B Bolyard)
Date: Sat, 7 Nov 2009 02:00:45 +0100 (MET)
In-Reply-To: <> from "Nelson B Bolyard" at Nov 6, 9 04:16:14 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal06
X-SAP: out
Subject: Re: [TLS] 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 01:00:27 -0000

Nelson B Bolyard wrote:
> Here is an alternative that should have the same user experience and not
> be MITM vulnerable, not even with SSL 3.0 clients:
>    Replace renegotiation with redirection.
> Set up a second https server (process) on the same physical server, e.g
> a different port on the same IP address.  The new server always requests
> client authentication on the initial handshake, not in a renegotiation.

That is actually what our clients usually have to do since the
OEM SSL/TLS library we provide does not support renegotiation on
the server side (its also not in our apps software layers).

There is one itch I have with this:
A number of Web Proxies (like the one of our company) does not
permit HTTP CONNECT to ports other than 443.

Should we ask for an additional port to be officially allocated
to http-over-ssl-with-client-cert so that we can get this past
our security policy (not joking)?