Encrypt all the websites!
SSL is everywhere—or at least major security supporters want it to be. The EFF has long pushed HTTPS Everywhere through browser extensions. ‘SSL Verified’ icons can be found embellishing retail sites of every size, and even Google is supporting efforts by giving SSL-secured sites a boost in search ranking.
As HTTP/2 makes its way toward standardization, it has made optional the requirement for SSL/TLS communications, but browsers that support the would-be standard are taking a stand and are supporting only HTTP/2 over SSL/TLS.
SSL will be everywhere and you will like it.
But is it really making us safer? While it’s certainly difficult to argue against securing any and all communications, we may be doing a disservice to users by promoting SSL encrypted sites as the be-all and end-all of safety.
We’ve seen malware continue to evolve to become more sophisticated in the last few years. The now active Dyre, for example, exploits not only vulnerabilities in Adobe to propagate but also turns trust in SSL to its advantage.
Once infected, a victim is lulled into a false sense of security by the ‘lock’ icon they’ve been taught to look for. However, under the hood, Dyre is capturing and transmitting sensitive information before encryption occurs and sending it off to its own dropzone. It also installs a rogue certificate for its proxy servers as a trusted root certificate, enabling the proxy to perform man-in-the-middle attacks, while maintaining a valid SSL connection. The ‘lock’ icon assures users, of course, that the communications are safe, even though they are most assuredly not.
Not content to simply circumvent the security implied by the use of SSL, Dyre itself has recently upgraded to use it for its own communications, ensuring outbound security services are unable to peek into the packets the malware sends to its dropzone.
Encryption does nothing to stop any of this. Indeed, with Dyre we’re seeing the exact scenario SSL and TLS encrypted sessions are supposed to prevent – that of MITM attacks – being conducted with impunity and with users none the wiser.
Luckily, the list of Dyre command and control proxies is hardcoded and can be prevented from making connections with financial institutions or users. But we can’t get complacent about it.
Just as other malware, such as Neverquest, has managed to evolve and circumvent two-factor authentication, it’s as sure as death and taxes that malware like Dyre will mutate yet again as it determines how to eliminate this weakness in its architecture.
All this points to a single inescapable fact: encryption is not a panacea. In elevating encryption to technological sainthood we’ve instilled in users a trust of technology that can be – and is being – exploited.
Certainly, we could stop Trojans like Dyre if users would stop falling victim to phishing attacks. We’ve been trying that for years, and have had what most would consider Pyrrhic success if any at all.
Efforts to instill in users trust of the lock icon is unlikely to remain a winning strategy for the future, either, given not only the rise of malware but vulnerabilities like Heartbleed that obliterated the myth that SSL-secured websites are safe from exploitation.
While encryption certainly shouldn’t be abandoned (one could easily argue the significant lack of MITM attacks over the past 20 years is precisely because of encryption in the first place), we need to re-evaluate web application security and how it’s provided for apps running in browsers and on mobile devices.
We need to rely on encryption as just one arm in a poly-armed approach to detecting and preventing the fraud and theft currently driving malware architecture and design.
Application security is a stack, reaching from the transport layers where SSL provides in-flight privacy up to the application layer protocols right into the application itself, where individual data values have the potential to break wide open the databases holding our most valued personal information.
We can’t stop at the first layer with encryption; we need to continue up the stack into the application. Today, that means we need to secure both the server-side and the client because logic and data reside on both.
We’ve long resisted securing the client, primarily given what would be a Sisyphean effort to do so when we have to protect consumers whose devices are not under our control. But the nearly ubiquitous use of cloud, the availability of real-time intelligence services, and the ability to inject the equivalent of client-side agents (scripts) may provide us with the means to do so without breaking our own backs or budgets by not relying on users to install more bulky agents requiring more concentrated management.
Whatever the ultimate solution, we need to have one. We can’t keep treating the client as sacrosanct when attackers are well aware they are the most vulnerable component in the transactional chain.
Simply requiring SSL or TLS and encryption in browsers and mobile apps isn’t enough to protect against threats able to compromise the client. Canonizing encryption has the effect of lulling users – and sometimes security operations – into a false sense of security.
Neither business nor users can (literally) afford the price of complacency.
About the Author: Lori MacVittie is responsible for evangelism across F5’s entire portfolio including a broad set of network and application security solutions. Prior to joining F5, MacVittie was an award-winning technology editor at Network Computing Magazine with a focus on applications and security. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.
Editor’s Note: The opinions expressed in this and other guest author articles are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.
The Executive’s Guide to the Top 20 Critical Security Controls Tripwire has compiled an e-book, titled The Executive’s Guide to the Top 20 Critical Security Controls: Key Takeaways and Improvement Opportunities, which is available for download [registration form required].
Image courtesy of ShutterStock.