Chrome have recently introduced new cipher suite support in chrome and chromium (NSS and OpenSSL patches are nearby too). This cipher was described in http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-02 with the following codes:
I guess that's why https://www.ssllabs.com/ssltest/viewMyClient.html fails to process Chrome's SSL/TLS handshake.
At this moment these are the 5 top cipher suits in chrome:
Note that all of these suites use key size = 128bit, while Firefox 25 top 10 suites are 256-bit. Meh, at least all these 128-bit suites are supposed to be fast.
More information about Chacha20 and Poly1305 can be found at https://www.imperialviolet.org/2013/10/07/chacha20.html
Your analysis is correct; the test was failing because of the unknown cipher suites. I have now added the 3 suites to my list, and the test is working for me for Chrome 33.
Thanks for reporting this problem. I wasn't aware they were going to support the suites so quickly.
BTW, Adam points out that ChaCha20 is a 256-bit cipher:
You know what? Chrome 33-dev is already here! Chacha20/Poly1305 suite was disabled (at least in 33.0.1712.2 dev-m), but SSL Client Test is broken again. There are nothing unusual in cipher suits at first glance, but there are few new tls extensions.
The first one was added 12 days ago: "SSL Padding" (code and 0x8B47), already in dev builds.
2 days ago another extension "SSL Channel ID" (code 0x7550) was pushed into Chromium repo.
And yesterday yet another extension
"Signed Certificate Timestamp" (a. k. a. Certificate Transparency, code 0x12) was added.
"SSL Channel ID" and "Signed Certificate Timestamp" are not in Chrome dev builds yet, but should be there very soon. You can see all TLS extensions supported by Chrome here.
Updated. Thanks for the ping.
BTW, I might have mentioned this before, but the test is designed to fail hard whenever something unknown is encountered. That ensures that we either report good results, or nothing at all.