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

Michael D'Errico <> Tue, 25 May 2010 15:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF49B3A69B0 for <>; Tue, 25 May 2010 08:41:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.754
X-Spam-Status: No, score=-0.754 tagged_above=-999 required=5 tests=[AWL=-0.569, BAYES_40=-0.185]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Snvy1A-kkkx9 for <>; Tue, 25 May 2010 08:41:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3B5703A6916 for <>; Tue, 25 May 2010 08:41:29 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 6B1F7B695D; Tue, 25 May 2010 11:41:20 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=qsl1y2kXWle2 4bPvJlm+KUPYrTY=; b=vhN+4ityf3p7mDaI+dX9XZZqfZa1wXpQUCi3cvgkU80W uK2wL+QkP1QV0FvtVrevbBBerp54zOVLOxtJK+8RV12iBMzGdZddotB8eD16l/o3 nIiXSalxYdlE3T60cVxzzqmvA1SdikA/mtjdyFaRroFRFsP0nADHfeDTIs/vzOg=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=M/82Zf YomK3YwZeNWBmsuJu46DI/wlVFJVSZhCW2MYYDSs9/YNI1qC8GvyLK0lt5f+QNVc mfeV22w8BsCLt4G7g7jEvAPvnv/sI0mopK9+yxMVj7Zyl95/gVkh+EfGu+r+jaFq GKWBMenTWi4WCyzW/5I85PKDt0jUm7EcLnC1s=
Received: from a-pb-sasl-quonix. (unknown []) by (Postfix) with ESMTP id 57290B695B; Tue, 25 May 2010 11:41:19 -0400 (EDT)
Received: from administrators-macbook-pro.local (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id F3500B6959; Tue, 25 May 2010 11:41:16 -0400 (EDT)
Message-ID: <>
Date: Tue, 25 May 2010 08:41:15 -0700
From: Michael D'Errico <>
User-Agent: Thunderbird (Macintosh/20090812)
MIME-Version: 1.0
References: <op.vc9kdggnvqd7e2@killashandra.oslo.osa>
In-Reply-To: <op.vc9kdggnvqd7e2@killashandra.oslo.osa>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: F67A226A-6813-11DF-A7F8-6730EE7EF46B-38729857!
Subject: Re: [TLS] RFC-4366-bis and the unrecognized_name(112) alert
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: Tue, 25 May 2010 15:41:30 -0000

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.


Yngve Nysaeter Pettersen wrote:
> Hello all,
> In the past few of weeks a couple of servers supporting SNI has come to 
> my attention because they send the Warning alert "unrecognized_name" 
> (112) in response to their actual name (that is, it should have 
> recognized the name, and not sent that Warning).
> It seems like these servers have started to use the SNI functionality in 
> the underlying TLS implementation, but that there is a problem with 
> configuring the handling of the extension and keeping it in sync with 
> the rest of the configuration. That is a problem for the vendor.
> RFC 4366-bis currently says:
>    If the server understood the client hello extension but
>    does not recognize any of the server names, it SHOULD send an
>    unrecognized_name(112) alert (which MAY be fatal).
> My question is: What should a client do if it receives this alert as a 
> Warning?
> AFAICT there are several options:
>   - Ignore it (several clients appears to do this currently). If so, 
> what is the use-case for this warning?
>   - Always ask the user. He or she probably won't understand the issue, 
> and will click through anyway.
>   - Check the certificate, and either warn the user if it does not match 
> (which all browsers would do anyway without the alert; so why need the 
> alert?), or escalate to Fatal.
>   - Always escalate to Fatal (which is what Opera currently does)
> What was the original reasoning for making the alert only optionally 
> Fatal? Why not always Fatal, or always Warning?
> May I suggest that the spec is updated with some advice for how a client 
> should behave when it receives the alert as a Warning?