Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer Security (TLS) Extensions: Extension Definitions) to Proposed Standard

Dean Anderson <dean@av8.com> Wed, 23 September 2009 19:03 UTC

Return-Path: <dean@av8.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 32E4C3A6A40; Wed, 23 Sep 2009 12:03:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.555
X-Spam-Level:
X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 eHR7-0L-CHqu; Wed, 23 Sep 2009 12:03:04 -0700 (PDT)
Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 3479B28C0E9; Wed, 23 Sep 2009 12:02:56 -0700 (PDT)
Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id n8NJ40fX016874 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 23 Sep 2009 15:04:00 -0400
Date: Wed, 23 Sep 2009 15:04:00 -0400 (EDT)
From: Dean Anderson <dean@av8.com>
X-X-Sender: dean@citation2.av8.net
To: Simon Josefsson <simon@josefsson.org>
In-Reply-To: <87ab0lskpf.fsf@mocca.josefsson.org>
Message-ID: <Pine.LNX.4.44.0909231500110.8840-100000@citation2.av8.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: ietf@ietf.org, tls@ietf.org
Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer Security (TLS) Extensions: Extension Definitions) to Proposed Standard
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: Wed, 23 Sep 2009 19:03:05 -0000

Is that insecure?

If the client is authorized by certificate, then it seems that it has 
that identity in addition to any application level identities.

The only insecurity is if the certifiate private key has been
compromised, which isn't something that TLS can protect against.

One problem with using TLS for virtual web hosts is that the server
names cannot match the single name allowed in the certificate.  I don't
want to see that get worse; I'd like to see it get better.

		--Dean

On Wed, 23 Sep 2009, Simon Josefsson wrote:

> I am aware that the IETF-wide last call has ended, but Daniel Black
> provided a suggestion (posted on the gnutls-devel list) for the Security
> Considerations that I agree with and believe can be important.  Quoting
> him, slightly reworded:
> 
>   also maybe 11.1. could say, in response to the last paragraph of
>   section 3, + "Server applications SHOULD validate server_name against
>   any application layer equivalent field."
> 
> The last paragraph of section 3 reads:
> 
>    If an application negotiates a server name using an application
>    protocol and then upgrades to TLS, and if a server_name extension is
>    sent, then the extension SHOULD contain the same name that was
>    negotiated in the application protocol. If the server_name is
>    established in the TLS session handshake, the client SHOULD NOT
>    attempt to request a different server name at the application layer.
> 
> It appears security relevant for the server to actual verify that the
> client do not use another server name at the application layer to
> circumvent authorization decisions.  I cannot find any MUST/SHOULD
> requirement in the document for servers to test this right now.
> 
> 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.
> 
> /Simon
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 256 5494