Relaxed SSL in android devices?

I apologize for the yellow title, but I think it is really worth discussing.

So, according to the author of the APRSdroid application, starting with Android 2.3, when setting up an SSL connection, instead of the previously used combination of AES256 and SHA1 encryption and hashing algorithms, a significantly weaker combination of RC4 and MD5 was first proposed.
Read the post with a description of this discovery, you can link .
Leaving behind the motives of the android developers, set the priority for these algorithms, I want to tell RC4 what is bad as the main encryption method and what is fraught with for SSL.

RC4 cipher vulnerability

RC4 is a stream cipher, with an internal state consisting of 256 elements. In fact, RC4 consists of two parts:

• Initialization algorithm - the encryption key is sent to the input of the algorithm. The algorithm fills the internal state of the cipher and performs mixing by permutations defined by the key.
• Pseudo-random number generator - mixes the internal state and returns a pseudo-random sequence of bytes.

In the future, the generated gamma is summed modulo two with open data, and a ciphertext is obtained.
The most important condition imposed on stream ciphers is the absolute indistinguishability of the PRNG gamma produced by a random sequence of bytes.
The problem is that RC4 does not meet this condition.
It was found that each of the first 256 bytes of the output sequence of RC4 has a different probability than zero from 1/256.
This means the following. Suppose an attacker was able to collect a fairly large number of the same message, 256 bytes in length, encrypted with various keys. Since the likelihood that each of the 256 bytes of the gamma used for encryption is zero above the average of 1/256, an attacker can check every byte of all available ciphertexts and with a large degree of success assume that the most frequent byte is the original one. By opening byte by byte, an attacker can uncover the entire message.
')

SSL write protocol

Now let's talk about how this all applies to SSL.
So, after the session key is formed, as a result of the handshake protocol, all further traffic will be encrypted using RC4.
The first RC4 encrypted message is a data block called Finished. Finished serves to confirm the establishment of communication. It consists of 36 bytes, generated each time in a new way. Accordingly, for an attacker, deciphering this block is not possible.
As a result, there are 220 bytes of useful information that can be revealed using this attack. And this is bad news, because this is enough to recover your password or cookies.

Fortunately, there is a good one. To date, the attack is difficult to implement in practice. As I wrote for the autopsy, you need to collect a large number of the same encrypted text. The creators of the attack claim that 2 ²⁶ ciphertexts are needed to recover 80 bytes from 256. To open the entire block with a length of 256 bytes, you need 2 ³² .
For the first time, a successful attack on this vulnerability was carried out in March 2013. Therefore, it can be said that this is a very new and very promising type of attack, which is very likely to be improved soon.

In conclusion, I would like to insert a few words about the whole situation that has developed around the SSL protocol lately. Honestly, it all surprises me a little. Cryptography in recent years has progressed greatly. The new standard SHA-3 is indistinguishable from the random oracle. Asymmetric cryptosystems are being developed that are resistant to attacks on quantum computers. Encryption modes appear that guarantee both authentication and confidentiality of the message. But with all this, we still use the protocol 14 years ago. Maybe it's time to try something newer? Otherwise, we will increasingly be "pleased" with the headlines that someone, somewhere, uses a weakened version of SSL.

Links

A brief description of the attack.
Bruce Schneier about the attack.
Detailed description (pdf)