JEP 114: TLS SNI Extension - SunJSSE Behavior Changes (Continue)

Students Apartment, Harbin Institute of Technology (HIT), China

The implementation of JEP 114 (TLS Server Name Indication (SNI) Extension) had integrated into JDK 8 at October, 2012. In the previous blog entry, we talked about the behavior changes in client and server mode. This blog entry will continue to talk about behavior changes in key manager and trust manager of JSSE. Please refer to javax.net.ssl package of JDK 8 APIs for the detailed specification.

Server Name Indication (SNI) sensitive KeyManager


In JDK 7 and previous releases, the KeyManager of server is not server name indication sensitive. The KeyManager of SunJSSE provider does not check the server name indication in order to get the proper key and certificate.

In JDK 8, the KeyManager of server of SunJSSE provider will try check the server name indication in extension and select the appropriate keys according to requested server name indication.

For example, supposed that there are three key/cert entries in server key store. The subject of the certs are "cn=www.example.com", "cn=www.invalid.com" and "cn=www.example.net". When the client requested server name indication is "www.example.net", the server should be able to select the cert with subject "cn=www.example.net", rather than the other two certs.

Server name indication sensitive TrustManager


Endpoint identification can be based on IP address or literal hostname.

In JDK 7, if a SSL/TSL connection specified the literal hostname of the server, the hostname will be used to make the endpoint identification against the peer's identity presented in the end-entity X.509 certificate.

For example: 
 
        SSLSocketFactory factory = ...
        SSLSocket sslSocket = factory.createSocket("www.example.com", 443);


the hostname, "www.example.com" will be used to make the endpoint identification.




While for


        SSLSocketFactory factory = ...
        SSLSocket sslSocket = factory.createSocket("172.16.10.6", 443);




as the hostname is an IP address, the endpoint identification cannot be used for literal hostname.




In JDK 8, developers have a chance to explicitly set the server name indication with SSLParameters.setServerNames(List<SNIServerName> serverNames). The server name indication in client mode also has impact on endpoint identification.




In SunJSSE provider, in client mode, the endpoint identification in the implementation of X509ExtendedTrustManager will make use of the server name indication, retrieved by ExtendedSSLSession.getRequestedServerNames().




For example:


        SSLSocketFactory factory = ...
        SSLSocket sslSocket = factory.createSocket("172.16.10.6", 443);
        // SSLEngine sslEngine = sslContext.createSSLEngine("172.16.10.6", 443);
 
        SNIHostName serverName = new SNIHostName("www.example.com");
        List<SNIServerName> serverNames = new ArrayList<>(1);
        serverNames.add(serverName);
 
        SSLParameters params = sslSocket.getSSLParameters();
        params.setServerNames(serverNames);
        sslSocket.setSSLParameters(params);
        // sslEngine.setSSLParameters(params);


the hostname in server name indication, "www.example.com", will be used to make endpoint identification against the peer's identity presented in the end-entity X.509 certificate.





More blog entries about TLS Server Name Indication (SNI) Extension:

TLS Server Name Indication Extension and Unrecognized_name

JEP 114: TLS SNI Extension - SunJSSE Behavior Changes

JEP 114: TLS SNI Extension - Typical User Cases

JEP 114: TLS SNI Extension - Virtual Servers Dispatcher















































Popular posts from this blog









TLS Server Name Indication Extension and Unrecognized_name




















Image







   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








Read more










JSSE Oracle Provider Preference of TLS Cipher Suites





















         Perference Order    Value    Description       1    0xC0,0x24    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384       2    0xC0,0x28    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384       3    0x00,0x3D    TLS_RSA_WITH_AES_256_CBC_SHA256       4    0xC0,0x26    TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384       5    0xC0,0x2A    TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384       6    0x00,0x6B    TLS_DHE_RSA_WITH_AES_256_CBC_SHA256       7    0x00,0x6A    TLS_DHE_DSS_WITH_AES_256_CBC_SHA256       8    0xC0,0x0A    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA       9    0xC0,0x14    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA       10    0x00,0x35    TLS_RSA_WITH_AES_256_CBC_SHA       11    0xC0,0x05    TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA       12    0xC0,0x0F    TLS_ECDH_RSA_WITH_AES_256_CBC_SHA       13    0x00,0x39    TLS_DHE_RSA_WITH_AES_256_CBC_SHA       14    0x00,0x38    TLS_DHE_DSS_WITH_AES_256_CBC_SHA       15    0xC0,0x23    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256       16    0xC0,0x27    TLS_ECDHE_RSA_WITH_AES_1








Read more










JSSE Oracle Provider Default Disabled TLS Cipher Suites





















 The following TLS cipher suites are supported by Oracle provider, SunJSSE. These cipher suites are disabled by default because of one of the following reasons:   obsoleted weak cipher suites  anonymous cipher suites  no encryption cipher suites (null cipher)  Kerberos cipher suites   Cipher suites for Kerberos (KRB5) need additional KRB5 service configuration, and these cipher suites are not common in practice.    You are NOT supposed to use these cipher suites unless you really know what you're doing from a standpoint.           Perference    Value    Description       1    0x00,0x6D    TLS_DH_anon_WITH_AES_256_CBC_SHA256       2    0xC0,0x19    TLS_ECDH_anon_WITH_AES_256_CBC_SHA       3    0x00,0x3A    TLS_DH_anon_WITH_AES_256_CBC_SHA       4    0x00,0x6C    TLS_DH_anon_WITH_AES_128_CBC_SHA256       5    0xC0,0x18    TLS_ECDH_anon_WITH_AES_128_CBC_SHA       6    0x00,0x34    TLS_DH_anon_WITH_AES_128_CBC_SHA       7    0xC0,0x16    TLS_ECDH_anon_WITH_RC4_128_SHA       8    0x00,0








Read more