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










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