JEP 114: TLS SNI Extension - Typical User Cases

The implementation of JEP 114 (TLS Server Name Indication (SNI) Extension) had integrated into JDK 8 at October, 2012. In the previous two blog entries, we talked about the behavior changes in JSSE. Let's look at a few typical user cases. Please refer to javax.net.ssl package of JDK 8 APIs for the detailed specification.

Client side user cases

Case C-1: I want to access "www.example.com"
Set the host name explicit. 
    SNIHostName serverName = new SNIHostName("www.example.com");
    List<SNIServerName> serverNames = new ArrayList<>(1);
    serverNames.add(serverName);
    sslParameters.setServerNames(serverNames);
It is recommend that the client always specify the host name.

Case C-2: I don't want to use server name indication
The server side terminates the transaction if server name indication is presented. I cannot use server name indication because of the compatibility issues in server side.

Disable the server name indication with empty server name list:       
    List<SNIServerName> serverNames = new ArrayList<>(1);
    sslParameters.setServerNames(serverNames);

Case C-3: I want to access URL, "https://www.example.com"
Doing nothing in SunJSSE, the provider default behaviors will set the hostname for me. I don't have to care about what's the real server name indication.

But third parties' providers may not support default server name indication. It is recommended to use Case C-1 to be provider independent.

Case C-4: I want to switch a socket from server mode to client mode
The socket was in server mode, but I need it work in client mode. Firstly, need to switch the mode:Set the host name explicit.
    sslSocket.setUseClientMode(true);
Secondly, need to reset the server name indication parameters in server mode,  see case S-1~S-5 for different purposes.

Server side user cases

Case S-1: I want to accept all kind of server name indication
Doing nothing, the server will ignore the server name indication.

Case S-2: I want to deny all server name indication of type host_name
Set an invalid server name pattern for host_name:
    SNIMatcher matcher = SNIHostName.createSNIMatcher("");
    Collection<SNIMatcher> matchers = new ArrayList<>(1);
    matchers.add(matcher);
    sslParameters.setSNIMatchers(matchers);
Or define a new SNIMatcher extension, which the matches() method always returns false.
    class DenialSNIMatcher extends SNIMatcher {
        DenialSNIMatcher() {
            super(StandardConstants.SNI_HOST_NAME);
        }

        @Override
        public boolean matches(SNIServerName serverName) {
            return false;
        }
    }

    SNIMatcher matcher = new DenialSNIMatcher();
    Collection<SNIMatcher> matchers = new ArrayList<>(1);
    matchers.add(matcher);

    sslParameters.setSNIMatchers(matchers);

Case S-3: I want to be accessed as "www.example.com"
Set the recognizable server name for "host_name" as "www.example.com":
    SNIMatcher matcher =
        SNIHostName.createSNIMatcher("www\\.example\\.com");
    Collection<SNIMatcher> matchers = new ArrayList<>(1);
    matchers.add(matcher);
    sslParameters.setSNIMatchers(matchers);

Case S-4: I want to be accessed as "www.example.com" or "www.example.net"
Set the recognizable server name for "host_name" as "www.example.com"  or "www.example.net":
    SNIMatcher matcher =
        SNIHostName.createSNIMatcher("www\\.example\\.(com|net)");
    Collection<SNIMatcher> matchers = new ArrayList<>(1);
    matchers.add(matcher);
    sslParameters.setSNIMatchers(matchers);

Case S-5: I want to be accessed as any hostname in the example.com domain
Set the recognizable server name for "host_name" as "*.example.com":
    SNIMatcher matcher =
        SNIHostName.createSNIMatcher("(.*\\.)*example\\.com");
    Collection<SNIMatcher> matchers = new ArrayList<>(1);
    matchers.add(matcher);
    sslParameters.setSNIMatchers(matchers);

 Case S-6: I want to switch a socket from client mode to server mode
The socket was in client mode, but I need it work in server mode.  Firstly, need to switch the mode:
    sslSocket.setUseClientMode(true);
Secondly, need to reset the server name indication in client mode, see case C-1-C-3 for different purpose.

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