Developers › Security Group blog
About Opera 11.60 and new problems with some secure servers
After we released Opera 11.60 earlier this week, a few people reported problems with some secure sites, sites that had worked in Opera 11.52.
The affected servers must be upgraded to versions that are not affected by the observed problem.
These reports are not unexpected, as the problems are caused by one of the security patches introduced by Opera 11.60 for the so-called BEAST issue, reported by researchers Duong and Rizzo, an issue we posted about in September.
Also, the problems observed with these sites are not isolated to Opera, as other browser vendors have either already released versions with the same kind of protocol update or will soon do so. In addition to the browser updates, Oracle released a patched version of Java in October.
The issue that this patch mitigates is that when a server supporting SSL v3 or TLS 1.0 (TLS 1.1 and later are not affected) selects certain encryption methods, specifically Triple-DES or AES in Opera (ARC4/RC4 is not affected), an attacker that is able to both observe the encrypted datastream, and control specific parts of the plain text that is sent in that datastream, was able to discover data sent over that connection that the attacker could not control, such as the cookies used for that site. The attack has been known for a long time, but what Duong and Rizzo discovered was a way to increase the speed of the attack dramatically.
The attack only works when attackers can see the encrypted data sent immediately before the next block of data that they send and that gets encrypted, which offers a way to mitigate the problem.
What Opera and the other browser vendors have decided is that each block of application data (such as a secure HTTP request) will be split into two blocks of data that are encrypted separately. The first encrypted block only contains the first byte of the application data; the second block contains the rest of the data. The method is being called a "1/n-1" record split. This payload splitting prevent the attackers from being able to construct a block of application data that can help them guess the content of the data they did not control (e.g., the cookies).
However, a few secure servers are not standards compliant and do not tolerate that a HTTP request such as "GET / HTTP/1.0" is broken up into two blocks of separately encrypted SSL/TLS records, such as "G" and "ET / HTTP/1.0", and responds in a number of ways -- for example, by just closing the connection, never responding, or responding with a HTTP error messages.
Before releasing this patch we did some research with the TLS Prober to discover the extent of the problem.
The numbers indicate that up to 0.25% of servers may be affected by this issue, although not every one of these servers is affected, as it depends on the specific encryption method selected by the server; however, it is possible that at least 0.16% could be affected, as they either support AES or only support Triple-DES.
As far as we can tell from the recorded information about the affected servers, most of the affected sites seem to be using unidentifiable SSL/TLS front-ends, as there is no specific server software that stands out among the servers.
There is still some uncertainty about the precise numbers, since the automatic detection of problematic servers in the TLS Prober might still incorrectly flag a server as behaving incorrectly, although among the reported servers tested so far, they have all been detected as being non-compliant.
As mentioned above, all browser vendors have either shipped, or will soon be shipping, updates of their browsers that will implement this new countermeasure, so the operators of the affected servers should as soon as possible do one of the following:
The affected servers must be upgraded to versions that are not affected by the observed problem.
These reports are not unexpected, as the problems are caused by one of the security patches introduced by Opera 11.60 for the so-called BEAST issue, reported by researchers Duong and Rizzo, an issue we posted about in September.
Also, the problems observed with these sites are not isolated to Opera, as other browser vendors have either already released versions with the same kind of protocol update or will soon do so. In addition to the browser updates, Oracle released a patched version of Java in October.
The issue that this patch mitigates is that when a server supporting SSL v3 or TLS 1.0 (TLS 1.1 and later are not affected) selects certain encryption methods, specifically Triple-DES or AES in Opera (ARC4/RC4 is not affected), an attacker that is able to both observe the encrypted datastream, and control specific parts of the plain text that is sent in that datastream, was able to discover data sent over that connection that the attacker could not control, such as the cookies used for that site. The attack has been known for a long time, but what Duong and Rizzo discovered was a way to increase the speed of the attack dramatically.
The attack only works when attackers can see the encrypted data sent immediately before the next block of data that they send and that gets encrypted, which offers a way to mitigate the problem.
What Opera and the other browser vendors have decided is that each block of application data (such as a secure HTTP request) will be split into two blocks of data that are encrypted separately. The first encrypted block only contains the first byte of the application data; the second block contains the rest of the data. The method is being called a "1/n-1" record split. This payload splitting prevent the attackers from being able to construct a block of application data that can help them guess the content of the data they did not control (e.g., the cookies).
However, a few secure servers are not standards compliant and do not tolerate that a HTTP request such as "GET / HTTP/1.0" is broken up into two blocks of separately encrypted SSL/TLS records, such as "G" and "ET / HTTP/1.0", and responds in a number of ways -- for example, by just closing the connection, never responding, or responding with a HTTP error messages.
Before releasing this patch we did some research with the TLS Prober to discover the extent of the problem.
The numbers indicate that up to 0.25% of servers may be affected by this issue, although not every one of these servers is affected, as it depends on the specific encryption method selected by the server; however, it is possible that at least 0.16% could be affected, as they either support AES or only support Triple-DES.
As far as we can tell from the recorded information about the affected servers, most of the affected sites seem to be using unidentifiable SSL/TLS front-ends, as there is no specific server software that stands out among the servers.
There is still some uncertainty about the precise numbers, since the automatic detection of problematic servers in the TLS Prober might still incorrectly flag a server as behaving incorrectly, although among the reported servers tested so far, they have all been detected as being non-compliant.
As mentioned above, all browser vendors have either shipped, or will soon be shipping, updates of their browsers that will implement this new countermeasure, so the operators of the affected servers should as soon as possible do one of the following:
- Upgrade the server to a newer version that is not affected by the problem. This is a good idea in any case, since the affected servers are probably old and thus have other security problems, too.
- Configure the server to prefer the RC4 encryption method (which does not have the problem), but this will still cause the problem to appear if the client does not support RC4.
Readers' comments 11
Left under the original article, as archived.
About this article
| Published in | Security Group blog |
|---|---|
| Date | December 11, 2011 |
| Author | Yngve Nysæter Pettersen |
| Tags | TLS, SSL, Opera, TLS prober, vulnerability fix, Security Issue, 512-bit, browser, cabforum, Certificates, MD5, renego |
| Original | Internet Archive |
Bion BorysthenesSunday, December 11, 2011 4:15:56 PM
Yngve Nysæter PettersenSunday, December 11, 2011 5:20:26 PM
Charles SchlossSunday, December 11, 2011 5:20:58 PM
Charles SchlossSaturday, December 17, 2011 5:03:24 PM
Security mandates aim to shore up shattered SSL system
http://www.theregister.co.uk/2011/12/17/ssl_certificate_security_requirements/
Originally posted by yngve:
I herd they skipped it at the last minute
Yngve Nysæter PettersenSaturday, December 17, 2011 7:18:00 PM
Originally posted by Chas4:
Probably only a temporary delay, as it was caused by a newly discovered problem with a major server vendor.
blackcoderTuesday, December 27, 2011 8:23:58 AM
Opera 11.60, https://www.sprint.net not working
Yngve Nysæter PettersenTuesday, December 27, 2011 12:11:05 PM
I do notice that the site support SSLv2, inluding the weakest cipher suites, and that it is vulnerable to the full Renego request injection problem.
It also does not enable TLS Session resume.
So the site needs patching in any case.
Yngve Nysæter PettersenTuesday, December 27, 2011 4:25:13 PM
Charles SchlossFriday, January 6, 2012 4:32:20 PM
http://www.theregister.co.uk/2012/01/06/patch_tuesday_pre_alert_jan_2012/
Charles SchlossFriday, January 6, 2012 4:38:51 PM
even network map is blocked server side
Charles SchlossTuesday, January 10, 2012 8:39:18 PM
http://threatpost.com/en_us/blogs/microsoft-fixes-beast-ssl-bug-january-patch-tuesday-011012