Yoav Nir wrote:
The client sends a SNI extension with the name "svn.tools.ietf.org".
For some reason the server does not recognize the name. This is
particularly puzzling because the CommonName in the server certificate
is "*.tools.ietf.org", which is usually considered a match.
The server sends a warning-level "unrecognized name" alert, and the
client breaks the connection.
Here's what RFC 6066 has to say on the subject:
If the server understood the ClientHello extension but
does not recognize the server name, the server SHOULD take one of two
actions: either abort the handshake by sending a fatal-level
unrecognized_name(112) alert or continue the handshake. It is NOT
RECOMMENDED to send a warning-level unrecognized_name(112) alert,
because the client's behavior in response to warning-level alerts is
unpredictable.
Unpredictable indeed.
Anyway, the server is wrong to send the alert on two counts: the name
does match, and the warning-level alert violates a "NOT RECOMMENDED"/
There is no such thing as violating a NOT RECOMMENDED.
Only MUSTs and MUST NOTs can be violated.
The non-recommendation was added to rfc6066 after interoperability
failures had been noticed in the installed based, in particular from
warning-level "unrecognized_name" alerts.
Both previous versions of TLS extension SNI say:
http://tools.ietf.org/html/rfc3546#page-10
http://tools.ietf.org/html/rfc4366#page-10
If the server understood the client hello extension but does not
recognize the server name, it SHOULD send an "unrecognized_name"
alert (which MAY be fatal).
So there seem to be two problems:
- The server (svn.tools.ietf.org) does not seem to be sufficiently
aware of the server names that it is servicing.
If it takes more than a server configuration file change to make it
aware of that additional hostname, then there is a software bug in
the WebServer (or the TLS-implementation used by the web server).
- The TLS client implementation exhibits an insufficient amount of
common sense because it aborts on a warning level ssl alert,
resulting in an interop failure.
-Martin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf