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

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Tue, 25 May 2010 15:42:42 +0200

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?

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 25 May 2010 08:41:15 -0700

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.

Mike

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).
> 
> configuring the handling of the extension and keeping it in sync with 
> the rest of the configuration. That is a problem for the vendor.
> 
>   - Ignore it (several clients appears to do this currently). If so, 
> what is the use-case for this warning?
>

---

From: Martin Rex <[email-masked]>
Date: Tue, 25 May 2010 18:57:35 +0200 (MEST)

> 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.

Support for SNI is something that will at some point be adopted by
a server TLS stack, and it can easily happen before the application
(server) above is able to configure it appropriately.

This is particularly likely to happen if an updated TLS implementation is
made a drop-in replacement for a previous version without it and one
is distributing the updated TLS implementation into an installed base,
i.e. the TLS implementation is updated without touching application
code or configuration.

Usually, this indicates an avoidable and unnecessary backwards interop
problem created by the server TLS implementation.  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.

There are other unnecessary interop problems created by TLS implementations
that are sloppy.  Like TLS implementations sending out-of-order
certificate_list elements in Certificate handshake messages or
sending incomplete certification chains, that (server) lack more
that just a self-signed root certificate or that (client) do not
end at one of the trusted issuers announced by the server in the
certificate_authorities list of the CertificateRequest handshake
message.  While such behaviour might be helpful for automated
testing, it ought _NOT_ to be the default behaviour and only be
used when _explicitly_ requested by the calling application.

It is not a good idea for a protocol implementation to make a
remote peer suffer for a configuration problem that can be
only be fixed locally, in particular when it can be easily
detected locally.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 25 May 2010 10:58:17 -0700

Martin Rex wrote:
> An application which

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