Google Chrome security fail – Weak SSL ciphers first!

Summary

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 3.0.195.38 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.

Details

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 3.0.195.38:

Ciphers supported in s_server binary

TLSv1/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:

  • TLS_RSA_WITH_RC4_128_MD5
  • TLS_RSA_WITH_RC4_128_SHA
  • TLS_RSA_WITH_3DES_EDE_CBC_SHA
  • TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

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.

Thoughts

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!

Advertisements
This entry was posted in bugs, Security and tagged , , , , , , , , , , , , , , , , , , , , , , , , , . Bookmark the permalink.

3 Responses to Google Chrome security fail – Weak SSL ciphers first!

  1. Locks Free says:

    Hi, nice article ! Just a question though:
    You say that they didn’t write the code, but isn’t Google writting the main networking code (the webkit is only doing the rendering and V8 taking care of the Javascript) ?

  2. Crazy Bunta says:

    You are right, Google has probably written this code (this should be checked as so many open projects are merged in Chrome, we should be careful ^^), but in this post I just mentioned that the Google-hired “security researchers” probably did not πŸ™‚ (… hopefully!)

  3. krokodil says:

    Looks good on Mac with recent Chrome version:

    s_server -cert http://www.example.com.pem -www
    Ciphers supported in s_server binary
    TLSv1/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:
    ECDHE-ECDSA-AES256-SHA ECDHE-ECDSA-AES128-SHA ECDHE-ECDSA-RC4-SHA
    ECDHE-ECDSA-DES-CBC3-SHA ECDHE-RSA-AES128-SHA ECDHE-RSA-AES256-SHA
    ECDHE-RSA-RC4-SHA ECDHE-RSA-DES-CBC3-SHA ECDH-ECDSA-AES128-SHA
    ECDH-ECDSA-AES256-SHA ECDH-ECDSA-RC4-SHA ECDH-ECDSA-DES-CBC3-SHA
    ECDH-RSA-AES128-SHA ECDH-RSA-AES256-SHA ECDH-RSA-RC4-SHA
    ECDH-RSA-DES-CBC3-SHA AES128-SHA RC4-SHA
    RC4-MD5 AES256-SHA DES-CBC3-SHA
    DHE-DSS-AES128-SHA DHE-RSA-AES128-SHA DHE-DSS-AES256-SHA
    DHE-RSA-AES256-SHA EDH-RSA-DES-CBC3-SHA EDH-DSS-DES-CBC3-SHA

    New, TLSv1/SSLv3, Cipher is AES128-SHA
    SSL-Session:
    Protocol : TLSv1
    Cipher : AES128-SHA
    Session-ID: 139C9F577231D073B4835CE55B321E2D322CE01A13529A637AD595D2578F4300
    Session-ID-ctx: 01000000
    Master-Key: 590F95A8A01C99F71713377EEBC80E302E3F2A577100C5FCF3E57B2B2AFBC4EF1E3B816698F26AA39917CA0039E1F64B
    Key-Arg : None
    Start Time: 1276020575
    Timeout : 300 (sec)
    Verify return code: 0 (ok)

    1 items in the session cache
    0 client connects (SSL_connect())
    0 client renegotiates (SSL_connect())
    0 client connects that finished
    2 server accepts (SSL_accept())
    0 server renegotiates (SSL_accept())
    1 server accepts that finished
    0 session cache hits
    0 session cache misses
    0 session cache timeouts
    0 callback cache hits
    0 cache full overflows (128 allowed)

    no client certificate available

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s