SSL is broken. So what?

[Usr6]

It is hard to ignore the recent news about government sponsored internet surveillance campaigns, which are alleged to involve decrypting SSL traffic. In light of these news, should you do anything differently? Does it matter to your network and how? Even if today only a small group possesses the knowledge and resources to decrypt SSL, chances are that this secret will leak like so many and the resources required to apply the techniques will only get cheaper and in turn become available to well funded advisories like organized crime. The information once decrypted may also be at risk from being compromised by anyone who compromised the organization that now holds the data. So does it matter?

First of all, I don't think there is "proof" at this point that SSL in itself has been broken. SSL and the encryption algorithms it negotiates have seen many implementation issues in the past, and it is fair to assume that broken implementations, bad random number generators and sub-optimal configurations make breaking "real live" SSL a lot easier then it should be based on the strength of the underlying algorithms. Additionally, in many high profile attacks, SSL wasn't the problem. The end point or the SSL infrastructure was compromised instead and as a result, the encryption algorithm didn't matter.

Endpoint Security

None of the "APT" style data leaks had much to do with decrypting SSL. Instead, the end point was compromised either by exploiting a technical vulnerability in client software, or by using social engineering techniques to trick the user into installing malicious software. These techniques are old, constantly tweaked and not limited to sophisticated attacks. Each day, we see compromises ranging from the "trivial" fake UPS shipping e-mail over more clever compromised ad networks to highly targeted and well crafted "spear phishing" attacks.

What is the "Endpoint"?

Many systems promise "end-to-end" encryption. In my opinion, end-to-end encryption means that a message is encrypted by the sender before it is transmitted and decrypted by the *final* recipient. The definition of *final* is critical here. Many encrypted messaging systems will decrypt the message on a server, then re-encrypt it for the recipient. This scheme will expose your message to intercept at the relay point. If you do not control the relay point, then your message is at risk from being intercepted. For example Skype. Skype uses a pretty solid encryption system. But in order to support features like gateways to other phone systems, the respective gateway has to be able to decrypt the message. Whenever your secure messaging system is able to communicate with insecure endpoints, someone else has to be able to decrypt the message. Similar with webmail systems. There are some attempts to built end-to-end encrypted web mail systems that use client side JavaScript or browser plugins to encrypt and decrypt the message. But these systems are not in wide use at this point. Cloud based messaging systems are of course in particular suspect and need to be designed carefully not to allow decryption "in the cloud", which in turn breaks features like search and indexing using cloud resources.

The SSL Infrastructure

There are two ways to "sniff" SSL: On the one hand you can record an SSL encrypted session and decrypt it offline. Without knowledge of the private keys or master keys involved, this process is very difficult if possible at all. The much more commonly used method to intercept SSL is to use a "Man in the Middle" attack. It again concerns the "end-to-end" concept. The attacker terminates the SSL connection and then re-encrypts it for the intended recipient. SSL provides signed certificates to prevent this attack, and clients will warn the user if an invalid certificate is used. The first problem is that the user may ignore the warning, given that too many "real" SSL certificates are not configured properly and produce this warning. Secondly, a browser will consider a certificate as valid if it is signed by a trusted certificate authority. Certificate authorities have been compromised in the past. Many governments control certificate authorities and are able to generate trusted certificates to impersonate other sites. Human factors around certificate authorities and attackers being able to obtain valid certificates are a much larger threat and SSL may have been considered broken for some time as a result. Tools like sslstrip will of course prey on the human interface component to again lead to a more "elegant" man in the middle attack.

So what should I do?

In network security, you always got limited time and limited resources to fight unlimited worries. First, focus on your end points. You are much more likely to suffer from a compromise due to a misconfigured endpoint then a brute-force decrypted SSL session. Secondly, double check the configuration of your SSL clients and servers. Are you using the strongest possible encryption algorithm? Are you using the longest possible keys? This is a tradeoff. For example, not all systems do support anything beyond TLS 1.0. Add respective upgrades to your roadmap. Finally: Encrypt everything. Even a sophisticated adversary has to use some finite resource to decrypt traffic. Increasing the work load by encrypting all traffic, not just "important" traffic is one way to extend the life span of your information. For closed networks that do not have to communicate with the outside world, consider building your own SSL infrastructure (NOT implement your own SSL library). Setup your own CA and only trust certificates signed by your own CA. But in the end, spend your time on problems that matter. It is all too easy to get distracted by the headline of the day.

Sursa: ISC Diary | SSL is broken. So what?