How secure is HTTPS with weak ciphersuites?
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
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.