Close Close Comment Creative Commons Donate Email Add Email Facebook Instagram Mastodon Facebook Messenger Mobile Nav Menu Podcast Print RSS Search Secure Twitter WhatsApp YouTube

What Heartbleed Means for Newsrooms

What newsroom developers can do about the Heartbleed security bug.

This post was co-published with Source.

Heartbleed is a security vulnerability that affects recent versions of OpenSSL, a popular software library that provides encryption. It is used in a wide variety of software in common use in news organizations, including the widely used open-source web servers Apache and Nginx (Microsoft's IIS web server is not affected). Think of SSL/TLS as the "S" in HTTPS.

Heartbleed is named after the part of SSL/TLS that it attacks -- a "heartbeat," which is the signal that client software sends to an Internet server to keep a network connection alive. The attack causes the web server to inadvertently send back a lot of extra data along with its heartbeat signal. This data consists of recent information from a server's RAM, which could include a server's private SSL encryption keys, user cookies and even user passwords.

The leak of SSL private keys is particularly alarming, since it might let an adversary decrypt all of a site’s encrypted communication, including any encrypted packets the adversary’s been storing. (Decryption of stored packets can be prevented by using forward secrecy, which is used in some newer versions of the SSL/TLS protocol but is not yet widely in use.)

Does This Affect Me?

If your websites have SSL enabled (when users log in, for example), or if you use VPN software to secure your network, or if you run your own mail servers, your newsroom might be affected by Heartbleed.

Heartbleed can affect anything that uses OpenSSL version 1.0.1 or greater. This includes most open-source webservers (Apache, nginx, lighttpd), and can include email servers, instant message services (ejabberd, etc), and VPN servers (openvpn). Privacy software like Tor and SecureDrop are also vulnerable and have since released updates. Many popular server operating systems are affected and have released patches that fix the bug, including Linux distributions like Ubuntu, Debian, Fedora, Red Hat Enterprise and Arch Linux.

It’s important to note that OpenSSL is a library that is dynamically linked to other software. The bug will affect any software that uses it. You can see what version of OpenSSL your operating system has by running this command:

$ openssl version
OpenSSL 1.0.1g 7 Apr 2014

If you get a version between 1.0.1 and 1.0.1f, you may be vulnerable. Some Linux distributions include a hotfix for this bug while keeping the same version number, so you should double-check the operating system's website for more information.

Software using other SSL/TLS libraries, like GnuTLS, PolarSSL and Mozilla NSS are not affected. This also includes some proprietary software, such as Microsoft’s Exchange and IIS, which use their own implementation of SSL/TLS. But be aware that some network hardware solutions — such as routers, firewalls or VPN appliances — may contain OpenSSL. When in doubt, you should check with your vendor or run your own tests.

One of the security researchers that discovered the blog has compiled more information on the bug — and affected products — at The Carnegie Mellon University Computer Emergency Response Team (CERT) has also compiled a partial list of affected vendors.

What Should I Do?

You can test your web server on this website or with this command-line tester. You'll need to check every domain you have an SSL certificate for -- be especially mindful if your organization has a separate "login" domain name, separate from the main site. And you can test non-web services like e-mail by including the SSL port number.

If you use one of the Linux operating systems mentioned, check the announcement for affected versions and update instructions:

Remember that you may need to restart the services running so that the update is properly enabled -- i.e., "sudo service nginx restart" or the similar command your Linux distribution uses to restart a daemon.

If your infrastructure relies on Amazon AWS, Heroku or other cloud services, you should also check with that service provider for other information that may affect you.

Updating software is not the only thing you have to do. Because the bug might have leaked your server’s SSL private key, you should also revoke and re-generate your SSL certificates. (The instructions vary from SSL provider to SSL provider, but you'll need to go through most of the steps to generate and install the new key as if you are starting from scratch.) This is because an attacker with your private key can easily decrypt all encrypted traffic to and from your server. Revoking the old certificate tells the internet that the old key has been compromised and that any websites using it might be fake.

You should alert your users to change their passwords once you have fixed Heartbleed on your servers.

Of course, you should also tell your newsroom that they should be careful about logging into affected servers and should change their passwords just about everywhere, once the websites have been patched This is especially important on publicly available services they use for work, including your CMS's admin screens, comment moderation services, social media, etc. A list of popular websites affected as of 2 p.m. Eastern Time on Tuesday was posted by Donnie Berkholz, a software developer and analyst.

Everyone in your newsroom should also double-check that their web browsers check for certificate revocation. This ensures that a connection to an HTTPS server isn't using a certificate that may have been compromised in the attack -- a sign that you may be talking to a fake website.

  • Chrome: Preferences -> Show advanced settings… ->HTTPS/SSL “Check for server certificate revocation”.

  • Firefox: Preferences -> Advanced -> Certificates -> Validation -> “Use the Online Certificate Status Protocol (OCSP) to confirm the current validity of certificates”.

  • Safari on Mac OS X: Open Keychain Access (in Applications -> Utilities) -> Preferences -> Certificates -> Set both “Online Certificate Status Protocol (OCSP)” and “Certificate Revocation List (CRL)” to “Require if certificate indicates”. Set “Priority” to “Require both”.

  • Internet Explorer: Tools -> Internet Options -> Advanced. Check “Check for publisher’s certificate revocation” and “Check for server certificate revocation”.

Further Reading

Portrait of Mike Tigas

Mike Tigas

Mike Tigas was the Lead Product Developer, DevOps and Security at ProPublica. He is also the developer of Tabula, a data extraction tool for PDF files, and Onion Browser, an open source web browser for iOS which uses the Tor anonymity network.

Latest Stories from ProPublica

Current site Current page