Taking a tour with Chrome on Windows XP, I’ve noticed connections to SSL/TLS sites were apparently limited to 128 bits encryption using XXX cipher (yes Chrome cannot display the currently used SSL cipher…. but that bug is apparently being worked on)… That got my curiosity ^^ and turned out to hide a security weakness in Chrome’s SSL support.
The sites I usually visit negotiate AES cipher and 256bits key length when using Firefox 3.5.6, so why would Chrome be stuck on the very same sites to 128 bits and sometimes 168 bits ???
The answer is simple: the strongests and ONLY encryption ciphersuites Google Chrome version 18.104.22.168 can negotiate for SSL/TLS are 3DES-EDE (168bits key) and RC4 (128bits key), with MD5 or SHA1 hashing.
The preferred SSL/TLS ciphersuite being RC4 (128bits key) with MD5 hashing!
You heard right, RC4 ! You know that futuristic cipher designed in … 1987 😉 Yes, the same cipher used for WEP and that got pretty much pwned a few years ago and pwned-again more recently (aircrack anyone?). And MD5, well I’m sure you know MD5 should now be avoided as much as possible, considering that collision attacks are on the rise, meaning the end of this algorithm as a secure hashing function. Even NIST in june 2005 was not really happy to let you use RC4 and MD5 in SSL/TLS ^^ My quick tests revealed that there is no support for AES.
So to the Google folks that might get this post before I post a bug report (if I ever do, so lazy etc), please have a look at OWASP, for example this page, and PLEASE activate the use of stronger ciphers like AES or Blowfish with all available key sizes. I don’t know for you, but 256 bits makes me feel warmer when I go on a banking Website…
I just cannot understand such a mistake… my thoughts at the end of this post.
I tried to get a better look in the code (opensource rox! and BTW I really want to thank Google who chose to contribute to the community by using Webkit and other opensource projets, that’s awesome!) but online parsing is not really easy and my current connection cannot handle the 800 megs of Chromium tarballs right now 🙂
Test using OpenSSL test Webserver
I still wanted to know what ciphersuite was used so I downloaded OpenSSL for Windows and launched a test HTTPS Web server using the following command line:
openssl s_server -cert mycert.pem -www
mycert.pem is a self-signed SSL certificate I generated for this test.
Then point your favorite browser to https://localhost:4433. You get a page generated by OpenSSL.
Using Google Chrome 22.214.171.124:
Ciphers supported in s_server binaryTLSv1/SSLv3:DHE-RSA-AES256-SHA TLSv1/SSLv3:DHE-DSS-AES256-SHA TLSv1/SSLv3:AES256-SHA TLSv1/SSLv3:EDH-RSA-DES-CBC3-SHA TLSv1/SSLv3:EDH-DSS-DES-CBC3-SHA TLSv1/SSLv3:DES-CBC3-SHA SSLv2 :DES-CBC3-MD5 TLSv1/SSLv3:DHE-RSA-AES128-SHA TLSv1/SSLv3:DHE-DSS-AES128-SHA TLSv1/SSLv3:AES128-SHA TLSv1/SSLv3:IDEA-CBC-SHA SSLv2 :IDEA-CBC-MD5 SSLv2 :RC2-CBC-MD5 TLSv1/SSLv3:RC4-SHA TLSv1/SSLv3:RC4-MD5 SSLv2 :RC4-MD5 TLSv1/SSLv3:EDH-RSA-DES-CBC-SHA TLSv1/SSLv3:EDH-DSS-DES-CBC-SHA TLSv1/SSLv3:DES-CBC-SHA SSLv2 :DES-CBC-MD5 TLSv1/SSLv3:EXP-EDH-RSA-DES-CBC-SHA TLSv1/SSLv3:EXP-EDH-DSS-DES-CBC-SHA TLSv1/SSLv3:EXP-DES-CBC-SHA TLSv1/SSLv3:EXP-RC2-CBC-MD5 SSLv2 :EXP-RC2-CBC-MD5 TLSv1/SSLv3:EXP-RC4-MD5 SSLv2 :EXP-RC4-MD5 --- Ciphers common between both SSL end points: RC4-MD5 RC4-SHA DES-CBC3-SHA DES-CBC-SHA EXP-RC4-MD5 EXP-RC2-CBC-MD5 EDH-DSS-DES-CBC3-SHA EDH-DSS-DES-CBC-SHA --- New, TLSv1/SSLv3, Cipher is RC4-MD5 SSL-Session: Protocol : TLSv1 Cipher : RC4-MD5
In this example we see that Chrome did not propose to use AES although the server supports it, and negotiated RC4-MD5. The same test on Firefox 3.5.6 negotiates AES256-SHA1.
The problem with this test is that the downloaded version of openssl does not support 3DES, too bad. Let’s try something else…
Go look the Wireshark
Well I took Wireshark for Windows and tried to go to an HTTPS Web page. I then looked for the TLS “Client Hello” message which contains all ciphersuites supported by the browser.
Google Chrome tries to negotiate 11 ciphersuites. FYI, Firefox 3.5.6 negotiates 35, still with security as with many things, quantity != quality. My eye/google-parsing of the online chromium source code taught me that some of them will never be used: those that have a key size under 80 bits! Good (security) idea 🙂 From the 11 ciphersuites, that would be: RSA-DES-CBC-SHA, RSA-EXP-RC4-56-SHA, RSA-EXP-DES-CBC-SHA, RSA-EXP-RC4-40-MD5, RSA-RC2-40-CBC-MD5 (OMG, RC2!!!), DHE-DSS-DES-CBC-SHA, DHE-DSS-EXP-DES-CBC-SHA.
Wewww, a lot! That leaves us with the following ordered list:
So indeed, Chrome has only 3DES-EDE (168bits keys) with SHA1, and RC4 (128bits keys) with MD5 or SHA1.
On top of that, as openssl explains: “Although the server determines which cipher suite is used it should take the first supported cipher in the list sent by the client.”, it is now also clear that the RC4-MD5 is preferred to the RC4-SHA1 and actually to all other supported ciphers, including 3DES! Bad bad bad security practice…
Now it’s clear for me: no more Chrome to check my bank account! 🙂
Note: The current stable version of Iron is, of course, also affected.
Hummm, doesn’t that choice of ciphers remind you something? Probably many things like “you have no privacy, get over it?” or recent/recurrent Windows issues regarding weak internal encryption? National Security-Specialized Agencies years ahead in terms of cryptanalysis? ^^
Well, without going further down this road with no end, I’m simply a bit concerned about this choice. I mean, Google hired top-notch security researchers that know all this well… at least they should! It’s true that they are not the ones doing the code, but hey, architecture, design choices, reviews, these words mean anything to Google? Of course they do! It’s the Big G! 😉 They have talented and hard working folks, so what? “I don’t know” is a simple answer, but I’ve come to learn that stupid mistakes happen quite often in large companies, this very fact can also be used by companies to put out carefully planned strategies behind these random “mistakes”.
As a side thought, talking about the security researchers at Google, they do a lot of vulnerability research on NON-Google products, hummm interesting. Is that just a “side-effect” of all the AWESOME work they do on G-products back there? ^^ Or is it that Big G is interested in finding as much (traditional) Windows/Linux OS bugs and even writing exploits, so that the sales people can put in their slides that “traditional computing is too dangerous, you should use Chrome OS !!!” (The Cloud is not dead yet people, please FINISH HIM and get over it while you still can 🙂 ) Or is it that Big G wants people to think, “oh yeah they have great security researchers! that’s so great that Google is doing so much in security (got it? ^^)! I’ll stick with G forever”… in our current “participation age” (or lets-be-owned-but-connected-get-over-it), it might very well work… Or is it that Big G is getting too rich and is not focusing ? I don’t believe that.
I’m sure this bug will be quickly fixed as it’s really not a coding challenge at all, it’s even strange there is no AES support at all, even I have already coded an openssl multi ciphersuites client/server and it’s really not a big deal at all (and I’m not a professional coder).
The question I like here is: why choose RC4 and 3DES, and discard AES in Google Chrome? Many possible answers, I leave this as an exercise for the reader 😉 Feel free to comment if you feel like it.
On a “personal” security point of view, I don’t like 3DES because making something broken work multiple times itself with rules is still something somehow broken to me, and indeed there already exists some attacks. I prefer AES in this respect. Even if 128bits might very well already be broken by some (latest attack papers are old, probably not a good sign when you continue to see computing power rising and you know the security barrier for AES is the number of rounds…), so 256bits (more rounds!) are good if you want some priva–.
Oh wait, but I have no privacy! Like I have no human rights! All these are ideals that can never be reached, so why bother?
Get Over It! … and Get Over It Fast!