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

[Martin Rex <[e-mail]>]

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.

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