The situation became uncomfortable because we couldn't solve both problems, but also because both issues were of roughly the same risk. (Low.) Still, the end result was clear: RC4 affects everyone and cannot be mitigated; BEAST affects only a part of the user base and there isn't a workable exploitation path for it any more (we hoped). In addition, we knew that attacks against RC4 were going to get better; and that the attack surface vulnerable to BEAST likely to get smaller.

Is BEAST still a threat?

From this conclusion, the work that remained was to prove that the exploitation path used by BEAST was genuinely closed. We had no reliable information about that, and so I set out to test a bunch of browsers running on various platforms, read source code where available, and attempt to exploit BEAST myself.

The research required a lot of effort and time, mostly because I did not want just to run the existing exploit; I wanted to fully understand the attack as well as explore other potential attack vectors. Juliano and Thai (BEAST authors) have been very helpful answering my questions about their choices. I had detours, some because of real problems, some because of my mistakes. For a long time I thought BEAST was still exploitable because, to my great surprise, I discovered that the Same-Origin Policy (SOP) bypass that was used for BEAST still existed. Apparently, the fix for that problem was botched. Using this bypass, a MITM can still use a Java applet to instrument a victim's browser to encrypt arbitrary plaintext and send it to arbitrary hosts.

Fortunately, there have been many changes to how applets work since BEAST was originally discovered. For example, there are now always warnings before an applet is started. In my testing, the Java plug-in had no ability to access HttpOnly cookies; it couldn't even send them in a request, or receive any of them back. Most importantly, HTTPS request made by applets are encrypted using Java's TLS stack, not that of the host browser. Because Java does implement the 1/n-1 split, BEAST cannot be exploited.

Epilogue

Even though SSL Labs no longer penalizes sites that do not implement server-side BEAST mitigation, the problem remains for as long as we have a major browser without the fix. Although I don't believe that the problem is exploitable today, there might be other attack vectors we are not aware of. A new feature added to Safari could make it exploitable again tomorrow. Or, someone with more time on their hands could prove me wrong. For this reason, we need a healthy security margin, and we need Safari to implement the 1/n-1 split by default.

By the way, supporting TLS 1.1 and 1.2 does not actually address BEAST now or in the near future, even though these protocols do not have the predictable IV weakness that's exploited by the attack. The first problem is that most of the Internet still relies on TLS 1.0. Only about 18% of the servers tracked in SSL Pulse support TLS 1.2 today. Thus, even though the next generation of web browsers will all support TLS 1.2, it's going to take a while until the servers are upgraded.

But there is also the second issue, which is that all major browsers are susceptible to protocol downgrade attacks; an active MITM can simulate failure conditions and force all browsers to back off from attempting to negotiate TLS 1.2, making them fall back all the way down to SSL 3. At that point, the predictable IV design is again a problem. Until the protocol downgrade weakness is fixed, newer protocols are going to be useful only against passive attackers, but not against the active ones.

Spotlight

(IN)SECURE Magazine is a free digital security publication discussing some of the hottest information security topics. Learn about personal data bankruptcy and the cost of privacy, security and compliance, delivering digital security to a mobile world, and much more.

As ISPs, hosting providers and online enterprises around the world continue suffering the effects of DDoS attacks, often the discussions that follow are, “What is the best way to defend our networks and our customers against an attack?”

The code redirects visitors to another URL where the Fiesta exploit kit is hosted, which then tries to detect and exploit several vulnerabilities in various software. If it succeeds, the visitors are saddled with a banking Trojan.

Looking for an Android-based tablet for your child but don't know which one to choose? If you are concerned about the device's protection against random hackers, Bluebox Security has just released a review of the nine most popular Android tablet models aimed specifically at children.