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_128_CBC_SHA256
17 0x00,0x3C TLS_RSA_WITH_AES_128_CBC_SHA256
18 0xC0,0x25 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
19 0xC0,0x29 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
20 0x00,0x67 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
21 0x00,0x40 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
22 0xC0,0x09 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
23 0xC0,0x13 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
24 0x00,0x2F TLS_RSA_WITH_AES_128_CBC_SHA
25 0xC0,0x04 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
26 0xC0,0x0E TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
27 0x00,0x33 TLS_DHE_RSA_WITH_AES_128_CBC_SHA
28 0x00,0x32 TLS_DHE_DSS_WITH_AES_128_CBC_SHA
29 0xC0,0x07 TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
30 0xC0,0x11 TLS_ECDHE_RSA_WITH_RC4_128_SHA
31 0x00,0x05 SSL_RSA_WITH_RC4_128_SHA
32 0xC0,0x02 TLS_ECDH_ECDSA_WITH_RC4_128_SHA
33 0xC0,0x0C TLS_ECDH_RSA_WITH_RC4_128_SHA
34 0xC0,0x08 TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
35 0xC0,0x12 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
36 0x00,0x0A SSL_RSA_WITH_3DES_EDE_CBC_SHA
37 0xC0,0x03 TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
38 0xC0,0x0D TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
39 0x00,0x16 SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
40 0x00,0x13 SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
41 0x00,0x04 SSL_RSA_WITH_RC4_128_MD5
42 0x00,0xFF TLS_EMPTY_RENEGOTIATION_INFO_SCSV [1]

Note that the data was from the Java SE doc of SunJSSE provider.

[1] TLS_EMPTY_RENEGOTIATION_INFO_SCSV means that secure TLS renegotiation [RFC 5746] is supported.

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