IETF Logo Mail Archive

Re: [TLS] RFC-4366-bis and the unrecognized_name(112) alert

Michael D'Errico <mike-list@pobox.com> Tue, 25 May 2010 17:58 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 B65583A6974 for <tls@core3.amsl.com>; Tue, 25 May 2010 10:58:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.937
X-Spam-Level:
X-Spam-Status: No, score=-1.937 tagged_above=-999 required=5 tests=[AWL=0.662, 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 i7ff+rIg1+i9 for <tls@core3.amsl.com>; Tue, 25 May 2010 10:58:33 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 6FE6A3A6918 for <tls@ietf.org>; Tue, 25 May 2010 10:58:33 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 864B7B6F62; Tue, 25 May 2010 13:58:24 -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=MW3AMMV9qllH jBz0syBKwwujUgc=; b=TLCoOGVVBsl76ffWegULz4fLWt7WrVqAx49wy7ErIL8V fDq7+v52RZCKf3omU+sKGF3fN0JAM/oenJVf2TpD8TzYKqcCDc3dV3VzlBnF3s+x mAotVgOPULDmQpGP/rxhZxAepMjVjAtvUI7TpiYAjxlEazK2Ijg4EDlABGpQvjY=
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=qYkD2g /hxn2WsLi33PeIbuAVcNZ3AGC3Wo3Ryt6HNlwyadNTCUm+Yz2ZrxyYIwMMwH4e4+ r9v4WZQuXyX1uYAjG6wg46+w+1rNlzEfCrzKUt+XsU0hLHqJM/x+6J1DxJLfKVTI 3Agv8q6H3pQMBLmB+0FYyi2PWYqjdEHqXLo3c=
Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 5FCA9B6F61; Tue, 25 May 2010 13:58:22 -0400 (EDT)
Received: from administrators-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-quonix.pobox.com (Postfix) with ESMTPSA id E31D9B6F5F; Tue, 25 May 2010 13:58:18 -0400 (EDT)
Message-ID: <4BFC0FB9.5030908@pobox.com>
Date: Tue, 25 May 2010 10:58:17 -0700
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: mrex@sap.com
References: <201005251657.o4PGvZkE006346@fs4113.wdf.sap.corp>
In-Reply-To: <201005251657.o4PGvZkE006346@fs4113.wdf.sap.corp>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 1BC8509C-6827-11DF-A751-6730EE7EF46B-38729857!a-pb-sasl-quonix.pobox.com
Cc: tls@ietf.org
Subject: Re: [TLS] RFC-4366-bis and the unrecognized_name(112) alert
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, 25 May 2010 17:58:34 -0000

Martin Rex wrote:
> Michael D'Errico wrote:
>> In my server code, the SNI is checked to see if there is a matching
>> virtual host with that domain name.  If there is, then no alert is
>> sent.  If there is no matching virtual host, then it checks whether
>> there is a default virtual host set up.  If there is a default, then
>> an unrecognized_name alert is sent with the warning level.  When no
>> default is configured, the alert sent is fatal since the handshake
>> can not continue.
>>
>> The warning lets the client know that there was not a match, but that
>> the server can still continue using its default.
> 
> 
> While this behaviour appears quite sensible/plausible, it will lead
> to the behaviour in the wild that Yngve is reporting.
> 
> An application which
> does not configure any SNI characteristics, is not using SNI, and
> for these, the server TLS implementation should _NOT_ be sending
> SNI mismatch TLS alerts unless the application explicitly requests so.

My server code will not send an alert unless the client (a) sent an
SNI and (b) that SNI did not map to a virtual host.

So that should not cause a problem.

It might be a good idea to clarify when sending an unrecognized_name
alert would be appropriate and clarify that it can be just a warning
and what that means.

Mike

v2.23.0 | Report a Bug | By Email