Java Security: SunJSSE and TLSAES


TLSAES defines AES ciphersuites for TLS, and from TLS version 1.1, the AES cipher suites are merged in TLS specification. The AES supports key lengths of 128, 192 and 256 bits.  However, the TLSAES specification only defines ciphersuites for 128 and 256 bits keys.
In Java security context, there is a important concept, "jurisdiction policy". The JCA framework includes an ability to enforce restrictions regarding the cryptographic algorithms and maximum cryptographic strengths available to applets/applications in different jurisdiction contexts (locations). Any such restrictions are specified in "jurisdiction policy files".

Due to import control restrictions by the governments of a few countries, the jurisdiction policy files shipped with the JDK from Sun Microsystems specify that "strong" but limited cryptography may be used. An "unlimited strength" version of these files indicating no restrictions on cryptographic strengths is available for those living in eligible countries (which is most countries). But only the "strong" version can be imported into those countries whose governments mandate restrictions. The JCA framework will enforce the restrictions specified in the installed jurisdiction policy files. 

According to the default jurisdiction policy, AES_128 is the "strong" cryptography, but AES_256 is one of "unlimited strength" cryptographies, which means that AES_256 cannot be used with the default installed JDK jurisdiction policy files.

From JDK1.4.2, the SunJSSE provider supports a number of AES_128 and AES_256 cipher suites. In 1.4.2, AES_256 cipher suites were not enabled, even if the unlimited strength JCE jurisdiction policy files were installed.  From J2SE 5.0, AES_256 cipher suites are enabled automatically if the unlimited strength JCE jurisdiction policy files are installed.

OK, then here comes the conclusion now:
  1. For JDK 1.4.2, one need to explicit set the AES cipher suites in the codes in order to get it enabled. 
  2. For AES_128 cipher suites, one can use it with the default installed JDK.
  3. TLS does not define AES_192 cipher suites.
  4. For AES_256 cipher suites, one need to use the "unlimited strength" jurisdiction policiy files.

For JDK 6, the "unlimited strength" jurisdiction policiy files could be downloaded from "Other Downloads" on http://java.sun.com/javase/downloads/index.jsp, and there is a README file inside, which describe the export/import issues, and how to install the additional policies. Please DO read the export/import lines and make sure you are allowed to use those "unlimited strength" policies.

Linkage to the blog entry at blogs.Sun.COM

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