Today I came across the website https://mtgox.com/, which claimed to be secure because of the Verisign certificate. I checked the certificate out of curiosity (it's the first thing they claim, let's see how secure "secure" is), and it was 128 bits RC4 with MD5 for message authentication.

As far as my knowledge goes, is AES the best current symmetric encryption algorithm. RC4 seems okay too, but Wikipedia argues against its use in new systems. And then MD5... Despite the loads of criticism, is seems actually secure enough when you don't have a big enough bounty on a hash, but there still is a lot of criticism on using it.

Also note that the cleartext is partially known here, like parts of the <head> and certainly the doctype. I'm not sure if this can be used in an attack with RC4 though.

So how secure is this ciphersuite really? What would it take to tamper with this connection? Or what does it take to read the transmitted data, given unlimited time? And are there even lower suites in use, for example in common but somewhat dated browsers (like FF3.6, IE8, etc)?

  • "the certificate (...) was 128 bits RC4 with MD5 for message authentication." really, the certificate? ;)
    – curiousguy
    Aug 19, 2012 at 8:39
  • @curiousguy Right. I meant what Chromium said the connection was encrypted with ;)
    – Luc
    Aug 19, 2012 at 12:52

3 Answers 3


RC4 is now not considered secure, there are documents that explicitly forbid its use in TLS: RFC7465.

You should not use RC4 currently.

post updated as obsolete information about crypto is dangerous

Obsolete information, as posted in 2012:

RC4 is secure, in fact, if you're not using TLS 1.2 then you should be using RC4 to protect against BEAST.

MD5 is insecure, but if it's used as a MAC function it's not yet broken

To their credit, if you have disabled MD5 hash, it will negotiate with SHA-1, in fact, if you disable RC4 it will negotiate AES: https://www.ssllabs.com/ssltest/analyze.html?d=mtgox%2ecom&s=72%2e52%2e5%2e67

  • TLS1.0. How do I protect it against BEAST? And I thought it always tries to use the strongest ciphersuite...
    – Luc
    Aug 19, 2012 at 2:00
  • @Luc, to learn how to protect against BEAST, search this site: there is a great deal of information about how to protect against BEAST.
    – D.W.
    Aug 19, 2012 at 6:45

Known weaknesses of RC4, right now (March 2013), are statistical biases:

  • The first few bytes of the stream, especially the second byte, are quite biased, meaning that if an attacker observes a lot of SSL sessions, he could make a good guess of what the second byte sent by the client or the server could be (at the very start of the session). But that won't teach him much: the attacker already knows that the second byte sent by the client is an 'E' (for an HTTP 'GET' request) and the second byte sent by the server is a 'T' (for an HTTP response, which always begins with 'HTTP').

  • Other biases are about pairs of bytes which are less likely than they should. The bias can be exhibited after observing one gigabyte of RC4 output. But observing a bias in lab conditions, and deducing something on encrypted data, are two different things. There's no known way to turn this bias of RC4 into an actual attack on SSL (the most plausible scenario I have heard of involves observing a few billions of connections which all contain the same secret data, e.g. a cookie or a password, at a reliably predictable place -- it would only take a few thousand years of patient eavesdropping).

Known weaknesses of MD5, right now (March 2013), are:

  • Non-resistance to collisions (since Wang's attack in 2004).
  • Theoretical weakness with regards to preimages (but with a cost of more than 2123, it is quite far into the "theory only" realm).

Neither directly impacts MD5 when used in SSL. Indeed, SSL uses MD5 as part of HMAC, which has a "security proof" relating its security to whether the compression function used in MD5 is indistinguishable from a PRF. It is known that MD5's compression function is not a PRF; it has been known since 1996 and Dobbertin's work on that compression function. This makes the HMAC security proof "inapplicable". But that HMAC/MD5 is not proven to be secure, does not mean that it is proven to be insecure. No actual attack on HMAC/MD5 is currently known. Correspondingly, its use in SSL is still "safe".

This is corroborated with the situation of MD4, a predecessor of MD5. MD4 is very broken with regards to collisions, much more so than MD5 (it still takes a few seconds to build a MD5 collisions, while the same machine will build millions of MD4 collisions per second). A preimage attack on MD4 is also known, but theoretical only (cost in 2102). HMAC/MD4 has an "almost practical" attack, leading to forgeries in 258 queries (you have to convince the attacked SSL client or server to compute that many SSL records within the same session, on data that the attacker chooses, before producing one fake record). This means that if SSL was using MD4 instead of MD5, it would still be "practically safe" right now, and we would just have "advanced warning flags" about the need to migrate to something better. MD5 is, on all points, more robust than MD4, so there is no need to panic.

And, of course, none of this is related to the certificate. Whether the server will want to use RC4 or AES or MD5 or SHA-256 is not written in the certificate, and completely out of reach of whatever Verisign may want to do. The certificate's job ends at the server public key, and does not cover what the server does with that public key, let alone what the server does with any session key which was exchanged using the public key.


There are no known attacks on this ciphersuite. I would not call it "weak". Choosing this ciphersuite is not what I would call best practice -- but if someone else has made the choice for you and you are stuck using it, you will probably be fine. It is unlikely that it will be the weakest link in your system.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .