My Opera
On the Precariousness of RC4
By Sigbjørn VikSigbjorn. Wednesday, March 20, 2013 8:08:28 AM
RC4 is one of the most popular encryption methods used on the Web today. We are told that up to 50% of all connections use this, partly because some recent attacks on other encryption methods have left RC4 unscathed, and many web masters have chosen to move to RC4. However, new research has devised another attack, usable against RC4. While this attack is still not viable in practice against a regular web surfer, RC4 no longer offers any extra security margin, and should another or improved attack be found, RC4 would fall.
RC4 should work somewhat like a random number generator, producing random output. However, statistical flaws have been found in the output of the algorithm, so with detailed knowledge of the flaws and sufficient attempts to encrypt the same data, some of the original data can be recovered. The recent attack has analyzed the output of RC4, and found that with a few tens of millions attempts, data can be recovered. Given sufficient time, a tab left open in the background can make this amount of requests to a logged-in website, such as a bank, thus possibly revealing the cookie. However, even with a fast intranet connection, and consuming all available bandwidth 24 hours a day, this would take several days to acomplish, making this attack infeasible against regular web surfers.
However, we want our users to feel secure browsing the web, even if they don't know what encryption methods the servers they visit use. RC4 no longer offer this assurance on its own, so in Opera 12.15 we are adding some extra safeguards whenever using RC4, so Opera users can still feel absolutely secure. Even if a new and secret improvement to the attack should be found by a surveillance agency, Opera users should still have nothing to fear.
The first of our safeguards is to add some random data into the connection, so statistical methods will be less effective. We add this both at the beginning of a new connection, and at random intervals later. Second, if we detect something which looks like an attack, we disallow further communication with that set of domains. In practice, if the number of requests during a 24-hour interval is unrealistically high, we block further requests for the remainder of that interval. The set of domains is the same as the set of domains a cookie can be sent to, and includes subdomains.
Combined, these safeguards should reassure any concerned users, while RC4 gets slowly phased out on the web. The precautions are so general in nature that they should hopefully protect also against future flaws found in RC4.
RC4 should work somewhat like a random number generator, producing random output. However, statistical flaws have been found in the output of the algorithm, so with detailed knowledge of the flaws and sufficient attempts to encrypt the same data, some of the original data can be recovered. The recent attack has analyzed the output of RC4, and found that with a few tens of millions attempts, data can be recovered. Given sufficient time, a tab left open in the background can make this amount of requests to a logged-in website, such as a bank, thus possibly revealing the cookie. However, even with a fast intranet connection, and consuming all available bandwidth 24 hours a day, this would take several days to acomplish, making this attack infeasible against regular web surfers.
However, we want our users to feel secure browsing the web, even if they don't know what encryption methods the servers they visit use. RC4 no longer offer this assurance on its own, so in Opera 12.15 we are adding some extra safeguards whenever using RC4, so Opera users can still feel absolutely secure. Even if a new and secret improvement to the attack should be found by a surveillance agency, Opera users should still have nothing to fear.
The first of our safeguards is to add some random data into the connection, so statistical methods will be less effective. We add this both at the beginning of a new connection, and at random intervals later. Second, if we detect something which looks like an attack, we disallow further communication with that set of domains. In practice, if the number of requests during a 24-hour interval is unrealistically high, we block further requests for the remainder of that interval. The set of domains is the same as the set of domains a cookie can be sent to, and includes subdomains.
Combined, these safeguards should reassure any concerned users, while RC4 gets slowly phased out on the web. The precautions are so general in nature that they should hopefully protect also against future flaws found in RC4.
