Blog posts by Alexei Balaganski
As just about every security-related publication has reported today, a critical vulnerability in OpenSSL has been discovered yesterday. OpenSSL is a cryptographic software library, which provides SSL/TSL encryption functionality for network traffic all over the Internet. It’s used by Apache and nginx web servers that serve well over half of the world’s web sites, it powers virtual private networks, instant messaging networks and even email. It’s also widely used in client software, devices and appliances.
Because of a bug in implementation of TLS Heartbeat extension, remote attackers are potentially able to trigger a memory leak on an affected server and obtain different kinds of sensitive information including server’s private keys. The most embarrassing part of this is that the bug has been discovered in past OpenSSL releases dating back to 2012. Specifically, all OpenSSL versions from 1.0.1 to 1.0.1f are vulnerable. The bug has been fixed in the version 1.0.1g, released yesterday.
Needless to say, potential consequences of this vulnerability are huge. Any remote attacker can theoretically leak a server’s private key and then easily decrypt any past or future SSL-encrypted traffic from that server without leaving any traces of an attack. This means that simply patching the vulnerability is not enough; all services involved in handling sensitive information also have to change their private keys and reissue their SSL certificates.
If your server is compromised, the first step should be updating OpenSSL to 1.0.1g – all major Linux and *BSD distributions have already made updates available. If it’s not possible, you can recompile OpenSSL from the source code with heartbeat support disabled.
Unfortunately, it’s not possible to detect whether your server has already been attacked using this bug. So, to be on the safe side, you should consider reissuing your SSL certificates with new private keys.
One rather sad consequence of the whole Heartbleed debacle is that it delivered a serious blow to a major claim of open source proponents that open source software is inherently more secure because more people can inspect its source code and find possible vulnerabilities. While potentially it is true, in reality not many people would do that for such a large-scale project like OpenSSL just out of curiosity. I can only hope that finally someone will have a good reason to sponsor a proper security audit for OpenSSL and other open source security software.
This is also a good opportunity for service providers to upgrade their SSL key length to ensure more reliable encryption.
Since the documents leaked last year by Edward Snowden have revealed the true extent of NSA powers to dig into people’s personal data around the world, the topic of protecting internet communications has become of utmost importance for government organizations, businesses and private persons alike. This is especially important for email, one of the most widely used Internet communication services.
One of the oldest Internet services still in use (SMTP protocol has been published in 1982), email is based on a set of inherently insecure protocols and by design cannot provide reliable protection against many types of attacks. Hacking, eavesdropping, forged identities, spam, phishing – you name it. Yes, there have been numerous developments to improve the situation over the years: transport layer security, anti-spam and anti-malware solutions, even text encryption. However, all of them are considered optional add-ons to the core set of services, since maintaining backwards compatibility with decades-old systems prevents us from enforcing new security-aware standards and protocols.
For the same reason we cannot just abandon email and switch to new, more secure communication services: most of our correspondents still use email only. Companies providing secured email services have existed for over a decade, but their adoption rates have always been low. Security experts have been fighting this inertia for years, educating the public, developing new protocols and services and pushing for stronger regulations. Alas, people are lazy; they always tend to choose convenience over security.
At least, it was like that until last year. Thanks to Snowden, people suddenly realized that their confidential communications are not just theoretically vulnerable to hacking or other illegal activities. In fact, nearly all their communications are routinely siphoned to huge government datacenters, where they are stored, analyzed and matched to other sources of private information. Even worse, all this is completely legal under current laws, and Internet communications providers are forced to silently cooperate with intelligence services – no hacking required.
Finally, people started to take notice. Finally, not just corporate IT managers, but informed consumers have come to understand that the only reliable protection against all kinds of eavesdropping is end-to-end encryption. Unfortunately, it seems that not everyone understands what exactly “end-to-end encryption” is.
The reason that motivated me to write this post was an article titled “Google encrypts all Gmail communications to protect users from NSA snooping”. Several German email providers like GMX and web.de used the same rhetoric when they have announced similar functionality as well. Even De-Mail, which is a paid service from German government, does not offer mandatory encryption.
Of course, this statement cannot be further from reality. Yes, forcing all users to use encrypted SSL connection to a webmail service is good news. In fact, I would even recommend using a tool like HTTPS Everywhere to enable SSL automatically on many major websites, because it makes browsing more secure and provides protection against man in the middle attacks, which can steal your passwords.
However, when it comes to email, SSL will only protect the “first mile” of your message’s journey to its destination. As soon as it reaches your provider’s mail server, it will be stored on the disk in a completely unencrypted format, open for snooping to server administrators, secret services or hackers. When the message is relayed to the next mail server, chances are that the transport channel won’t be encrypted, too, simply because the other server does not support it. On its way, your mail will be read and analyzed by multiple servers and other devices (anti-spam services, antimalware appliances, firewalls with deep packet inspection and so on). Any of these devices can store a copy for later use or simply collect metadata in form of logs.
For companies like Google, being able to snoop through your emails is even fundamental for their business model: they need to serve you the most relevant ads, increasing their revenues. They can do it legitimately, because it’s part of their TOS. They will even share collected information with third parties. No kind of transport encryption will change that.
Companies building their business model on trust and aiming to provide a truly secure service, both in technical and legal terms, face a different kind of problem. They can simply be forced to hand all master keys over to the government, rendering all encryption useless. Thanks to Ladar Levison of Lavabit, we now know that, too.
Therefore, in my opinion, the only reasonable method of secure email currently available is to use a desktop mail program with a form of public key encryption to encrypt all outgoing mails directly on your computer and to decrypt them directly on the recipient’s computer. Unfortunately, several protocols currently in use (most common are S/MIME and OpenPGP) are incompatible and most mail programs require third party add-ons to implement them. In addition, before you’ll be able to encrypt your messages, you need to exchange encryption keys with the other party over a secure channel (not email!). And, of course, you should always keep in mind that merely the fact that you are using encryption may attract the attention of secret services: an honest man has nothing to hide, doesn’t he? Unfortunately, the way email works it cannot provide any kind of plausible deniability, since message metadata are never encrypted. That’s probably one of the reasons for the recent surge in popularity of ephemeral messaging services like Threema or Telegram, which at least claim not to keep any traces of your messages on their servers. Whether you should trust these claims is, of course, another difficult question…
By the way, the future of encryption and privacy-enabling technologies will be a big topic during our upcoming European Identity & Cloud Conference. Leading experts will join Ladar Levison himself to discuss technical, political and legal challenges. You should be there as well!
Register now for KuppingerCole Select and get your free 30-day access to a great selection of KuppingerCole research materials and to live trainings.
AI for the Future of your Business: Effective, Safe, Secure & Ethical Everything we admire, love, need to survive, and that brings us further in creating a better future with a human face is and will be a result of intelligence. Synthesizing and amplifying our human intelligence have therefore the potential of leading us into a new era of prosperity like we have not seen before, if we succeed keeping AI Safe, Secure and Ethical. Since the very beginning of industrialization, and even before, we have been striving at structuring our work in a way that it becomes accessible for [...]