JEP 115: AES-GCM CipherSuites in JDK 8

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_256_GCM_SHA384 (RFC 5289)
    TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (RFC 5288)
    TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (RFC 5288)
 
    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (RFC 5289)
    TLS_RSA_WITH_AES_128_GCM_SHA256 (RFC 5288)
    TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 (RFC 5289)
    TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 (RFC 5289)
    TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (RFC 5288)
    TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (RFC 5288)

The following SSL/TLS AEAD/GCM cipher suites are supported but not enabled by default in SunJSSE provider for TLS version 1.2: 
    TLS_DH_anon_WITH_AES_256_GCM_SHA384 (RFC 5288)
    TLS_DH_anon_WITH_AES_128_GCM_SHA256 (RFC 5288)

The following SSL/TLS AEAD/GCM cipher suites are defined, but not implemented or supported by SunJSSE provider:
    TLS_DH_RSA_WITH_AES_128_GCM_SHA256 (RFC 5288)
    TLS_DH_RSA_WITH_AES_256_GCM_SHA384 (RFC 5288)
 
    TLS_DH_DSS_WITH_AES_128_GCM_SHA256 (RFC 5288)
    TLS_DH_DSS_WITH_AES_256_GCM_SHA384 (RFC 5288)

For better compatibility and interoperability, in JDK 8, it is decided to decrease the preference priority of cipher suites in GCM mode for a while before GCM technologies mature in the industry. New developments in TLS security have occurred recently, the industry is moving towards TLS 1.1/1.2 and the use of GCM-based cipher suites. The preference priority of GCM-based cipher suites by default may be increased in JDK 9, or a JDK 8 update release in the future.

Enojoy this new feature!

Popular posts from this blog

NIST Security Strength Time Frames

Security Strength Time Frames of NIST SP 800-57 Part 1 Security Strength 80 112 128 192 256 applying processing applying processing through 2010 acceptable acceptable acceptable acceptable acceptable acceptable acceptable 2011 through2013 deprecated legacy use acceptable acceptable acceptable acceptable acceptable 2014 through 2030 disallowed legacy use acceptable acceptable acceptable acceptable acceptable 2031 and Beyond disallowed legacy use disallowed legacy use acceptable acceptable acceptable Symmetric Algorithms 2TDEA 3TDEA AES-128 AES-192 AES-256 FFC (e.g., DSA, D-H) L = 1024 N = 160 L = 2048 N = 224 L = 3072 N = 256 L = 7680 N = 384 L = 15360 N = 512 IFC (e.g., RSA) k = 1024 k = 2048 k = 3072 k = 7680 k = 15360 ECC (e.g.,ECDSA) f = 160-223 f = 224-255 f = 256-383 f = 384-511 f = 512+ Digital Signatures and hash-only applications SHA-1, SHA-224, SHA-256, SHA-384, SHA-5...
Read more

Use Braces Even For Single Line Statement

Image
On Feb. 21, 2014, Apple released security update for iOS that affected SSL/TLS connections. The impact is described as "An attacker with a privileged network position may capture or modify data in sessions protected by SSL/TLS." And the CVSS v2 Base Score is 6.8(AV:N/AC:M/Au:N/C:P/I:P/A:P). What's the problem with it? Here is the Apple code : static OSStatus SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams, uint8_t *signature, UInt16 signatureLen) { ... if ((err = ReadyHash(&SSLHashSHA1, &hashCtx)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &clientRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &has...
Read more

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