TLS Server Name Indication Extension and Unrecognized_name

Heavy Pond, Jianfengling National Forest Park, Ledong, Hainan, China

It's getting hot that some TLS/HTTPS server failed with "unrecognized_name". For example, the Adobe AIR 3 Code Signing Certificate Problem, the ADT handshake alert, and the jarsigner issue with timestamp.geotrust.com, etc. This entry will discussion some background of the "unrecognized_name" alert, and the TLS Server Name Indication (SNI) extension.

Background


"Unrecognized_name" is an error alert, define by RFC4366.  In section 4 of RFC4366: 
- "unrecognized_name": this alert is sent by servers that receive a server_name extension request, but do not recognize the server name.  This message MAY be fatal.
And in section 3.1 of of RFC4366: 
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).

From above sections, we see that "unrecognized_name" is related to "the server name" or "server_name" extension. What is the "server name"? In section 3.1 of RFC4366: 
3.1. Server Name Indication 

TLS does not provide a mechanism for a client to tell a server the name of the server it is contacting.  It may be desirable for clients to provide this information to facilitate secure connections to servers that host multiple 'virtual' servers at a single underlying network address.

In order to provide the server name, clients MAY include an extension of type "server_name" in the (extended) client hello.

Let's Look Into a Case


There is a lot of discussion about the timestamp service from timestamp.EXAMPLE.com. The service is hosted as "https://timestamp.EXAMPLE.com/tsa". Let's look at the scenarios of the access:


  1. Client want to negotiate a TLS connection with timestamp.EXAMPLE.com. By default, the server name indication extension will be included in the client hello. The server name is "timestamp.EXAMPLE.com".  It is expected that:
    • The server does not understand the server name indication extension. No problem, the server will ignore the extension, will continue the negotiation.  No impact on the TLS negotiation/handshaking.
    • The server understands the server name indication extension, but does not recognize the server  name. In this case, that's to say, the server does not think that the server name in the request, "timestamp.EXAMPLE.com", is its supported/recognized server name.
    • The server is able to recognize the server name in the request. The handshaking will go on.

  2.  The server response with a "unexpected_message" fatal alert. As means that the server understand the server name indication extension, but it does not recognize the server name. It looks a little weird in this case in that the server is "timestamp.EXAMPLE.com", but it does not admit that it is "timestamp.EXAMPLE.com".
  3. The client have to terminate the negotiation because the server has denied to continue.

 It is strange, is it? The server, "timestamp.EXAMPLE.com", said it is not ""timestamp.EXAMPLE.com".

Know nothing about the details in TSA server, timestamp.EXAMPLE.com, it looks more like a configuration problem in the server side.

Workaround


It would be nice if the timestamp.EXAMPLE.com server would like to correct the behaviors in server side.  But before the correction, many applications may need to work day to day. As a workaround, the client can disable the server name indication in client hello.

Java platform starts to support server name indication extension from JDK 7.  However, considering the compatibility issues, a system property, "jsse.enableSNIExtension", is defined to disable the extension in TLS handshaking: 
jsse.enableSNIExtension system property.

Server Name Indication (SNI) is a TLS extension, defined in RFC4366.It enables TLS connections to virtual servers, in which multiple servers for different network names are hosted at a single underlying network address.

Some very old SSL/TLS vendors may not be able handle SSL/TLS extensions. In this case, set this property to false to disable the SNI extension.

OK, let looks at an example in jarsigner in JDK 7.  The 2nd one uses the system property, jsse.enableSNIExtension, to disable the server name indication extension in client. 
$ jarsigner -keystore myKeyStore -tsa https://timestamp.EXAMPLE.com/tsa \
      -signedjar signedjar.jar toBeSigned.jar myKeyAliasInKeyStore

jarsigner: unable to sign jar: javax.net.ssl.SSLProtocolException: \
      handshake alert:  unrecognized_name

$ jarsigner -J-Djsse.enableSNIExtension=false \
      -keystore myKeyStore -tsa https://timestamp.EXAMPLE.com/tsa \
      -signedjar signedjar.jar toBeSigned.jar myKeyAliasInKeyStore

Hope it helps!



More blog entries about TLS Server Name Indication (SNI) Extension:
JEP 114: TLS SNI Extension - SunJSSE Behavior Changes
JEP 114: TLS SNI Extension - SunJSSE Behavior Changes (Continue)
JEP 114: TLS SNI Extension - Typical User Cases
JEP 114: TLS SNI Extension - Virtual Servers Dispatcher

Popular posts from this blog

Java™ SE 7 Release Security Enhancements - Weak Cryptography Control

Weak cryptographic algorithms can now be disabled in Java SE 7 release. The MD2 Message-Digest Algorithm was disabled by default in Sun PKIX provider and SunJSSE provider. The MD2 algorithm is a cryptographic hash function developed by Ronald Rivest in 1989 , and was published in 1992 as an Informational RFC (RFC 1319) .; RFC 6149 moves RFC 1319/MD2 to historic status, "Since its publication, MD2 has been shown to not be collision-free, albeit successful collision attacks for properly implemented MD2 are not that damaging. Successful pre-image and second pre-image attacks against MD2 have been shown." Although MD2 is no longer considered secure, it remains in use in public key infrastructures as part of certificates generated with MD2 and RSA. An a countermeasure of the vulnerability, Java SE has disabled MD2 algorithm in certification path building and validation. You may wonder, Java SE has disabled MD2 algorithm in certification path building and validation in ...
Read more

JEP 115: AES-GCM CipherSuites in JDK 8

Image
Chengdu, China RFC 5288 describes the use of AES in Galois Counter Mode ( GCM ) (AES-GCM) with various key exchange mechanisms as a cipher suite for TLS. AES-GCM is an authenticated encryption with associated data (AEAD) cipher (as defined in TLS 1.2 ) providing both confidentiality and data origin authentication. Java SE had already defined the AES-GCM interfaces in Java SE 7 .  In the coming Java SE 8, as an implementation of JEP 115 , AES-GCM algorithms is implemented in SunJCE provider, and AES-GCM cipher suites are implemented in SunJSSE provider. The following SSL/TLS AEAD/GCM cipher suites, in preference order, are enabled by default in SunJSSE provider for TLS version 1.2: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (RFC 5289) TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (RFC 5289) TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (RFC 5289) TLS_RSA_WITH_AES_256_GCM_SHA384 (RFC 5288) TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 (RFC 5289) TLS_ECDH_RSA_WITH_AES_...
Read more