Blog: Webmasters FREAKed Out
The FREAK attack becomes possible when a client and server can be tricked into using very weak ciphers even when they would not normally do so. By default, two systems establishing an encrypted connection negotiate the best or preferred protocols they both support, and this is almost always a modern algorithm.
Once an encrypted connection has been forced down to a sufficiently weak cipher, the massive compute capability that is readily available in today's cloud systems can perform the calculations required to decrypt the communications in only a few hours and for only a few dollars.
So cryptographically, FREAK is a disaster. Encryption should not be so easily broken — even for very old algorithms.
In practice, it's no longer much of a problem. The attack is only possible due to software faults on clients, which have now been fixed (patches to iOS 8.2, OS X, Internet Explorer and others). And on the server-side, it's only possible when servers offer a particular suite of ciphers which have long been considered obsolete.
In 2014, the POODLE vulnerability revealed that SSL 3 was even less secure than previously thought. POODLE, like FREAK, is a protocol downgrade attack. Since then, the industry has decided to do more work retiring old encryption protocols, SSL 3 in particular, so that brand of downgrade attack has nowhere to go. On the client-side, SSL 3 support has been removed from most browsers, so the number of clients/servers with the potential to deliberately or accidentally communicate at this old protocol is reduced as low as possible. On the server-side, webmasters were supposed to reconfigure their servers to disable SSL 3.
But in 2015, the appearance of FREAK begs the question as to why so many sites are vulnerable to it, given the mad scramble to kill SSL 3? True, the attack vectors are different, but the fundamental issue is the same: wide support for obsolete, insecure protocols that should no longer be used.
Surely all the webmasters who mitigated their systems against POODLE took the opportunity to apply best-practices encryption hardening?
If they had, all those insecure ciphers would not be present, and FREAK would be a discussion about a hypothetical vulnerability that was virtually impossible to leverage. But it's not.
But what we find is that many of the sites vulnerable to FREAK are also vulnerable to POODLE, because those webmasters never actually mitigated their systems against POODLE in the first place.
Why would webmasters leave their systems vulnerable to POODLE? Why would they leave old protocols live on their systems, having been told in no uncertain terms how dangerous it had become?
One explanation for this is that website operators, loathe to take their production servers down and lose sales and/or page impressions, decided against doing anything about POODLE, because reconfiguring a server, although simple in theory, may have created longer outages from unintended consequences. And in any case, they may have considered, POODLE was being mitigated client-side thanks to the work of the web browser developers.
And now FREAK, albeit essentially a client-side issue, despite the complicity of servers which offer old ciphers, is receiving the same treatment. Webmasters are springing into action, waiting for clients to remediate.
This is not good practice.
Within 12 months, most Internet users will be immune to POODLE and FREAK attacks as their devices catch up with software updates. But there will be many — hundreds of millions — of devices which are either obsolete, not being patched by their manufacturers, or not auto-updating for some reason that will remain vulnerable.
This includes any old Apple device stuck on iOS 7 or less, many older Android systems, Blackberry and older Windows versions. The difficulty in updating even relatively new Android devices with security updates is a growing concern.
When these devices connect to servers still offering old protocols, the conditions are created for attacks against the communication which could reveal passwords and other sensitive information, and once an attacker has some entry into your network, even if it's just someone's login for Outlook Web Access, or the CRM portal, more sophisticated and more intrusive attacks become possible.
So webmasters still have a responsibility — to themselves and their users — to remediate their servers for known and unknown attacks against low-end encryption. The availability of massive compute in cloud systems makes attacks against encryption easier and more likely.