Xuelei Fan's Blog

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_...

The implementation of  JEP 114  (TLS Server Name Indication (SNI) Extension) had  integrated into JDK 8  at October, 2012. In  the previous blog entries , we talked about the behavior changes in JSSE, and a few typical user cases . Let's look at a special user case, how to design a virtual server dispatcher in Java. Please refer to javax.net.ssl package of  JDK 8 APIs  for the detailed specification. Prepare the ClientHello Parser Applications need to implementation their own APIs to parser the client hello message from a plaintext socket. Suppose that an application design the following API to do the work, SSLCapabilities and SSLExplorer. SSLCapabilities is defined to show the SSL/TLS security capabilities during handshaking, SSLCapabilities can be retrieved by exploring the network data of an SSL/TLS connection via SSLExplorer.explore(ByteBuffer). /** * Encapsulates the security capabilities * of an SSL/TLS connection. * * Th...

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 ser...

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 thre...

Silver Cave, Guilin, China The implementation of JEP 114 (TLS Server Name Indication (SNI) Extension) had integrated into JDK 8  at October, 2012. This blog entry will talk about some useful behavior changes and user cases that make use of SNI extenstion.  Please refer to javax.net.ssl package of  JDK 8 APIs for the detailed specification. The SNI extension in client mode In JDK 7, if a SSL/TSL connection specified hostname of the server, and when the hostname is fully qualified domain name (FQDN), the hostname will be used as the default server name indication in ClientHello message, implicitly. For example:     SSLSocketFactory factory = ...     SSLSocket sslSocket = factory.createSocket("www.example.com", 443); the hostname, "www.example.com" will appear in the server name indication extension in ClientHello message. While for     SSLSocketFactory factory = ...     SSLSocket sslSocket = factory.createSocket...

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...

Aged Bridge, Yulong River, Yangshuo, China Why Key Size Concerns The key size is an important security parameter to determine the strength of cryptography algorithms. For example, RSA keys with fewer than 1024 bits are considered forgeable.  If RSA keys less than 1024 bits are used in X.509 certificates, the private keys used in these certificates can be derived and could allow an attacker to duplicate the certificates and use them fraudulently to spoof content, perform phishing attacks, or perform man-in-the-middle attacks. On August 14, 2012, Microsoft offered an update to Windows that restricts the use of certificates with RSA keys less than 1024 bits in length.  As of October 9, 2012, the update is delivered via automatic update through the Microsoft update service.  Microsoft recommends that customers apply the update at the earliest opportunity. Since JDK 7u12,  RSA keys less than 1024 bits in X.509 certificates are disabled.  This...

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...

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 ...

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...

The protocol level TLS renegotiation Man-In-The-Middle (MITM) vulnerability has already been fully fixed in Java SE for quite a while.  The following table shows the status of JDK/JRE releases and updates to neutralize the vulnerability in Java. Renegotiation is Vulnerable Renegotiation is Disabled Renegotiation is Secure JDK/JRE 7 N/A N/A All releases JDK/JRE 6 Update 18 and earlier Updates 19-21 Update 22 JDK/JRE 5.0 Update 23 and earlier Updates 24-25 Update 26 JDK/JRE 1.4.2 Update 25 and earlier Updates 26-27 Update 28 Unfortunately, research shows many famous commercial sites on the Web have not yet upgraded their software, according to the last report, Potential Vulnerability status of major ecommerce sites (Please see my previous post ). Much worse, for some circumstance, it is not always easy to upgrade Java Runtime Environment. In such cases, we need workarounds to mitigate the impact of the vulnerability on vulnerable releases. T he Primary Countermeasu...

It's time to upgrade your Java Runtime Environment to JRE 6 update 22, JRE 5.0 update 26, or JRE 1.4.2 update 28 at least , or the latest updates . Sooner, rather than later! Java SE has implemented RFC 5746 , and fully fixed the TLS renegotiation MITM vulnerability from JDK 7 and above update release. Most of the SSL/TLS implementation vendors have already fixed the vulnerability in their product lines. Unfortunately, many famous commercial sites on the Web have not yet upgraded their software, according to the last report (by the edit time of this paper, it is Fri, Jul. 01, 2011) , Potential Vulnerability status of major ecommerce sites . If your site is in list of the above report , it is exposed to public that the site is unsafe. Your site in the risk of attack. Why not take action, right now?

My presentation about NIO.2 and JSSE in JavaOne Beijing 2010. The time has come for Web servers to handle tens of thousands of clients simultaneously. Using NIO.2, one of the major features of JDK 7, will prove to be a reliable approach to solving the C10K problem (the inability of most Web servers to handle more than 10,000 clients simultaneously). This session introduced NIO.2’s asynchronous I/O APIs and illustrated a simple framework for building a reliable, lightweight, secure server.

In JDK 7, "PKIX" was defined as the standard algorithm name of KeyManagerFactory. It's a factory for X509ExtendedKeyManagers that manages X.509 certificate-based key pairs for local side authentication according to the rules defined by the IETF PKIX working group in RFC 3280 or its successor. The KeyManagerFactory must support initialization using the class javax.net.ssl.KeyStoreBuilderParameters. Please refer to Java Security Standard Names .

NIST'S Policy on Hash Functions March 15, 2006: The SHA-2 family of hash functions (i.e., SHA-224, SHA-256, SHA-384 and SHA-512) may be used by Federal agencies for all applications using secure hash algorithms. Federal agencies should stop using SHA-1 for digital signatures, digital time stamping and other applications that require collision resistance as soon as practical, and must use the SHA-2 family of hash functions for these applications after 2010. After 2010, Federal agencies may use SHA-1 only for the following applications: hash-based message authentication codes (HMACs); key derivation functions (KDFs); and random number generators (RNGs). Regardless of use, NIST encourages application and protocol designers to use the SHA-2 family of hash functions for all new applications and protocols. TLS specifics of hash functions MAC constructionsA number of operations in the TLS record and handshake layer require a keyed Message Authentication Code (MAC) to protect mes...