Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer

Michael D'Errico <mike-list@pobox.com> Tue, 29 September 2009 04:27 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 59ACE28C0E1; Mon, 28 Sep 2009 21:27:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 sGkara1d9DYN; Mon, 28 Sep 2009 21:27:08 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 3389628C0EC; Mon, 28 Sep 2009 21:27:08 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 615F7631DA; Tue, 29 Sep 2009 00:28:26 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=1i6hCvMdnSOI bw7liJbNU6khhok=; b=k57B8ejRLUoBo8zZPqTqSTTzrePDWTkq62v/jJkvtKww r+k1C/Q+Ba0hfmkDHevV8ZtM9sexlw6+zyTz7zkzHdcx6G/X5jslMNm+ARvBVCxs bOo9lg2uDGtkiSmGDBD4vu+6gKbDk1FArtLraAEHEYUDT7IQT1QIW+ZWRGMW4HM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=OvsQxF IwjFPYJAWAQXJid+JrEf6wTWMjChLoNZ+iXgAMAQNfN/q44StJQWRdSOAutrLM62 oM2wCQhAgrXFuBgT5IPdX6n/m/X3WhmDiOBRknvdZi3GwaNYrQjWmZIOQOBJlo65 v9hqjoJAHFHltcFu8GOA8A+pzDa8mB30MPu0M=
Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 2FB6A631D9; Tue, 29 Sep 2009 00:28:23 -0400 (EDT)
Received: from michael-derricos-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 4AF05631D7; Tue, 29 Sep 2009 00:28:17 -0400 (EDT)
Message-ID: <4AC18CDC.40105@pobox.com>
Date: Mon, 28 Sep 2009 21:28:12 -0700
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: martin.rex@sap.com
References: <200909282121.n8SLLbm3006759@fs4113.wdf.sap.corp>
In-Reply-To: <200909282121.n8SLLbm3006759@fs4113.wdf.sap.corp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 861294B8-ACB0-11DE-B9F0-8B19076EA04E-38729857!a-pb-sasl-sd.pobox.com
Cc: Simon Josefsson <simon@josefsson.org>, ietf@ietf.org, tls@ietf.org
Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer
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: Tue, 29 Sep 2009 04:27:09 -0000

Martin Rex wrote:
> Simon Josefsson wrote:
>> One attack could works like this:
>>
>> 1) Client establish an client-authenticated HTTPS session with a TLS SNI
>> for blog.example.org and sends a HTTP GET with a Host: header for
>> internal-website.example.org.
>>
>> 2) The server TLS code authenticate and authorize the client (using the
>> certificate) for use with the blog.example.org domain.  The server HTTP
>> code serves the internal-website.example.org web page to the client.
>>
>> This system would be insecure but still compliant with RFC 4366bis as
>> far as I can tell, which seems suboptimal.  Adding a requirement for
>> servers to check for this attack would solve the problem.
> 
> I do not see why you consider this a vulnerability in the _server_!

Because a malicious client could theoretically establish a secure
connection using one server domain and then ask for pages from a
different domain.  If the server does not check for this, it could
potentially leak sensitive information.

> This is exactly how virtual hosting works.  Virtual hosting
> does NOT seperate content.  And neither will the use of TLS
> provide any such content seperation.  The use or non-use of
> server name indication does not make a difference.

Virtual hosting does indeed allow for separate content for each
domain.  Or am I misunderstanding you?

The reason for the server name extension is because, for HTTPS, the
TLS layer is negotiated prior to the client sending its HTTP request
containing the Host: header.  A server that hosts multiple domains
needs to use the SNI to negotiate the proper secure connection using
a certificate with a matching commonName or dNSName.

> Server Name Indication is a feature for the _client_ side, and was
> invented to accomodate virtual hosting when HTTP over TLS is used
> and the client performs weak server endpoint identification
> that is suggested by rfc-2818, section 3.1.

Perhaps it was originally a client feature, but my test server
has two certificate chains for two different domains, and it
negotiates TLS using one or the other depending on the SNI.  The
server name is then made available to the application layer.  I
don't know of any other way to do this since they share an IP
address.  (For anyone interested in testing against my server,
see http://mikestoolbox.com.)

And I'm curious: why do you call matching the commonName weak?

Mike


> If you can coerce a Browser into sending a Host: header field
> different to the host that is used for server endpoint identification,
> then this might possibly be considered a problem in the *client*.
> 
> When using Reverse Proxies with re-encryption, there may be
> a by-design difference in the SNI as supplied by the client
> (matching the hostname of the reverse proxy) and the
> host header field that the backend server is going to see/use.
> 
> -Martin