Google Chrome Preference of TLS Cipher Suites

Perference Order Value Description
1 0xC0,0x0A TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
2 0xC0,0x14 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
3 0x00,0x88 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
4 0x00,0x87 TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA
5 0x00,0x39 TLS_DHE_RSA_WITH_AES_256_CBC_SHA
6 0x00,0x38 TLS_DHE_DSS_WITH_AES_256_CBC_SHA
7 0xC0,0x0F TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
8 0xC0,0x05 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
9 0x00,0x84 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
10 0x00,0x35 TLS_RSA_WITH_AES_256_CBC_SHA
11 0xC0,0x07 TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
12 0xC0,0x09 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
13 0xC0,0x11 TLS_ECDHE_RSA_WITH_RC4_128_SHA
14 0xC0,0x13 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
15 0x00,0x45 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
16 0x00,0x44 TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA
17 0x00,0x66 TLS_DHE_DSS_WITH_RC4_128_SHA
18 0x00,0x33 TLS_DHE_RSA_WITH_AES_128_CBC_SHA
19 0x00,0x32 TLS_DHE_DSS_WITH_AES_128_CBC_SHA
20 0xC0,0x0C TLS_ECDH_RSA_WITH_RC4_128_SHA
21 0xC0,0x0e TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
22 0xC0,0x02 TLS_ECDH_ECDSA_WITH_RC4_128_SHA
23 0xC0,0x04 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
24 0x00,0x96 TLS_RSA_WITH_SEED_CBC_SHA
25 0x00,0x41 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
26 0x00,0x04 TLS_RSA_WITH_RC4_128_MD5
27 0x00,0x05 TLS_RSA_WITH_RC4_128_SHA
28 0x00,0x2F TLS_RSA_WITH_AES_128_CBC_SHA
29 0xC0,0x08 TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
30 0xC0,0x12 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
31 0x00,0x16 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
32 0x00,0x13 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
33 0xC0,0x0d TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
34 0xC0,0x03 TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
35 0xFE,0xFF SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
36 0x00,0x0a TLS_RSA_WITH_3DES_EDE_CBC_SHA

Note that the data was from the observation of the TLS ClientHello message when visiting a HTTPS web site from Google Chrome 14.0.

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