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

Martin Rex <> Mon, 07 June 2010 17:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C3D43A6F22 for <>; Mon, 7 Jun 2010 10:24:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.649
X-Spam-Status: No, score=-7.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kN1LqKHJOUlW for <>; Mon, 7 Jun 2010 10:24:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DA3D828C810 for <>; Mon, 7 Jun 2010 09:06:11 -0700 (PDT)
Received: from by (26) with ESMTP id o57EkZXO001676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Jun 2010 16:46:35 +0200 (MEST)
Received: from ( []) by (mail03-25) with ESMTP id o57EkTnf023491 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 7 Jun 2010 16:46:34 +0200 (MEST)
Received: (from d019080@localhost) by (8.13.4+Sun/8.13.4/Submit) id o57EkTuW029119; Mon, 7 Jun 2010 16:46:29 +0200 (MEST)
From: Martin Rex <>
Message-Id: <>
To: (Nikos Mavrogiannopoulos)
Date: Mon, 7 Jun 2010 16:46:29 +0200 (MEST)
In-Reply-To: <> from "Nikos Mavrogiannopoulos" at Jun 4, 10 07:43:07 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
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: Mon, 07 Jun 2010 17:24:15 -0000

Nikos Mavrogiannopoulos wrote:
> Michael D'Errico wrote:
> > I agree with Yngve that a server should send either an empty SNI
> > extension OR an unrecognized_name alert but not both.  However, I
> > disagree that the server SHOULD NOT send a warning alert since that
> > hides information from the client.
> [...]
> >     1 - server understood the SNI and used it to select an appropriate
> >         certificate chain and other parameters
> >     2 - server understood the SNI but did not recognize it as one of
> >         its configured virtual hosts; however, the server is set up
> >         to use a default configuration in that case
> >     3 - server understood the SNI but did not recognize it as one of
> >         its configured virtual hosts; there is no default configuration
> >         available so the handshake can not continue
> >     4 - server does not understand the SNI extension
> > 
> > The way my server reacts to each of these cases is:
> > 
> >     1 - add an empty SNI extension to ServerHello
> >     2 - send a warning unrecognized_name alert
> >     3 - send a fatal unrecognized_name alert
> >     4 - send nothing
> > 
> > Yngve would prefer that nothing is sent in case 2, but then a client
> > can not distinguish it from case 4.
> I believe that his point was, what can the client do anyway? In both
> cases the client just follows the handshake and will be prompted if the
> "default" certificate doesn't match the connected host. Would the client
> need to be warned that he is being connected using the "default"
> certificate rather than any specific?

I actually fail to see the exact purpose of a warning-level alert
"unrecognized_name".  The client is supposed to perform the server endpoint
identification in any case, and that warning should not affect the
outcome of that process at all.

Btw. this warning-level alert could be stripped from the handshake
by an attacker _without_ affecting the handshake message hash and
finished calculations (alerts are not handshake messages and are therefore
invisible to the handshake message hash).  Similarly, an attacker
can insert such a warning-level alert into handshakes without affecting
the handshake message hash.

I think there should be a guidance in the spec what the
receiver of that alert at level warning should do.

   A client that receives a warning-level "unrecognized_name" alert
   SHOULD ignore this alert and continue the TLS handshake.  The purpose
   of a warning-level "unrecognized_name" is for diagnostic purposes,
   if anything.

   A client TLS implementation MAY offer API functionality for the client
   application to determine what warning-level alerts were received
   during a TLS handshake.  When the server endpoint identification
   performed by the client application fails, then a client application
   might want to query whether any warning-level alerts have been
   received during the TLS handshake and mention these in the information
   presented to a user or written to a logfile for diagnostic purposes.