Tag: security

An Explanation of the Heartbleed bug for Regular People

I’ve put this explanation together for those who want to understand the Heartbleed bug, how it fits into the bigger picture of secure internet browsing, and what you can do to mitigate its affects.

HTTPS vs HTTP (padlock vs no padlock)

When you are browsing a site securely, you use https and you see a padlock icon in the url bar. When you are browsing insecurely you use http and you do not see a padlock icon.

Firefox url bar for HTTPS site (above) and non-HTTPS (below).
Firefox url bar for HTTPS site (above) and non-HTTPS (below).

HTTPS relies on something called SSL/TLS.

Understanding SSL/TLS

SSL stands for Secure Sockets Layer and TLS stands for Transport Layer Security. TLS is the later version of the original, proprietary, SSL protocol developed by Netscape. Today, when people say SSL, they generally mean TLS, the current, standard version of the protocol.

Public and private keys

The TLS protocol relies heavily on public-key or asymmetric cryptography. In this kind of cryptography, two separate but paired keys are required: a public key and a private key. The public key is, as its name suggests, shared with the world and is used to encrypt plain-text data or to verify a digital signature. (A digital signature is a way to authenticate identity.) A matching private key, on the other hand, is used to decrypt data and to generate digital signatures. A private key should be safeguarded and never shared. Many private keys are protected by pass-phrases, but merely having access to the private key means you can likely use it.

Authentication and encryption

The purpose of SSL/TLS is to authenticate and encrypt web traffic.

Authenticate in this case means “verify that I am who I say I am.” This is very important because when you visit your bank’s website in your browser, you want to feel confident that you are visiting the web servers of — and thereby giving your information to — your actual bank and not another server claiming to be your bank. This authentication is achieved using something called certificates that are issued by Certificate Authorities (CA). Wikipedia explains thusly:

The digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others (relying parties) to rely upon signatures or assertions made by the private key that corresponds to the public key that is certified. In this model of trust relationships, a CA is a trusted third party that is trusted by both the subject (owner) of the certificate and the party relying upon the certificate.

In order to obtain a valid certificate from a CA, website owners must submit, at minimum, their server’s public key and demonstrate that they have access to the website (domain).

Encrypt in this case means “encode data such that only authorized parties may decode it.” Encrypting internet traffic is important for sensitive or otherwise private data because it is trivially easy eavesdrop on internet traffic. Information transmitted not using SSL is usually done so in plain-text and as such clearly readable by anyone. This might be acceptable for general internet broswing. After all, who cares who knows which NY Times article you are reading? But is not acceptable for a range of private data including user names, passwords and private messages.

Behind the scenes of an SSL/TLS connection

When you visit a website with HTTPs enabled, a multi-step process occurs so that a secure connection can be established. During this process, the sever and client (browser) send messages back and forth in order to a) authenticate the server’s (and sometimes the client’s) identity and, b) to negotiate what encryption scheme, including which cipher and which key, they will use for the session. Identities are authenticated using the digital certificates mentioned previously.

When all of that is complete, the secure connection is established and the server and client send traffic back and forth to each other.

All of this happens without you ever knowing about it. Once you see your bank’s login screen the process is complete, assuming you see the padlock icon in your browser’s url bar.

Keepalives and Heartbeats

Even though establishing an ssl connection happens almost imperceptibly to you, it does have an overhead in terms of computer and network resources. To minimize this overhead, network connections are often kept open and active until a given timeout threshold is exceed. When that happens, the connection is closed. If the client and server wish to communicate again, they need to re-negotiate the connection and re-incur the overhead of that negotiation.

One way to forestall a connection being closed is via keepalives. A keepalive message is used to tell a server “Hey, I know I haven’t used this connection in a little while, but I’m still here and I’m planning to use it again really soon.”

Keepalive functionality was added to the TLS protocol specification via the Heartbeat Extension. Instead of “Keepalives,” they’re called “Heartbeats,” but they do basically the same thing.

Specification vs Implementation

Let’s pause for a moment to talk about specifications vs implementations. A protocol is a defined way of doing something. In this case of TLS, that something is encrypted network communications. When a protocol is standardized, it means that a lot of people have agreed upon the exact way that protocol should work and this way is outlined in a specification. The specification for TLS is collaboratively developed, maintained and promoted by the standards body Internet Engineering Task Force (IETF). A specification in and of itself does not do anything. It is a set of documents, not a program. In order for a specifications to do something, they must be implemented by programmers.

OpenSSL implementation of TLS

OpenSSL is one implementation of the TLS protocol. There are others, including the open source GnuTLS as well as proprietary implementations. OpenSSL is a library, meaning that it is not a standalone software package, but one that is used by other software packages. These include the very popular webserver Apache.

The Heartbleed bug only applies to webservers with SSL/TLS enabled, and only those using specific versions of the open source OpenSSL library because the bug relates to an error in the code of that library, specifically the heartbeat extension code. It is not related to any errors in the TLS specification or and in any of the underlying ciper suites.

Usually this would be good news. However, because OpenSSL is so widely used, particularly the affected version, this simple bug has tremendously reach in terms of the number of servers and therefor the number of users it potentially affects.

What the heartbeat extension is supposed to do

The heartbeat extension is supposed to work as follows:

  • A client sends a heartbeat message to the server.
  • The message contains two pieces of data: a payload and the size of that payload. The payload can by anything up to 64kb.
  • When the server receives the heartbeat message, it is to add a bit of extra data to it (padding) and send it right back to the client.

Pretty simple, right? Heartbeat isn’t supposed to do anything other than let the server and client know they are each still there and accepting connections.

What the heartbeat code actually does

In the code for affected versions (1.0.1-1.0.1f) of the OpenSSL heartbeat extension, the programmer(s) made a simple but horrible mistake: They failed to verify the size of the received payload. Instead, they accepted what the client said was the size of the payload and returned this amount of data from memory, thinking it should be returning the same data it had received. Therefore, a client could send a payload of 1KB, say it was 64KB and receive that amount of data back, all from server memory.

If that’s confusing, try this analogy: Imagine you are my bank. I show up and make a deposit. I say the deposit is $64, but you don’t actually verify this amount. Moments later I request a withdrawal of the $64 I say I deposited. In fact, I really only deposited $1, but since you never checked, you have no choice but to give me $64, $63 of which doesn’t actually belong to me.

And, this is exactly how a someone could exploit this vulnerability. What comes back from memory doesn’t belong to the client that sent the heartbeat message, but it’s given a copy of it anyway. The data returned is random, but would be data that the OpenSSL library had been storing in memory. This should be pre-encryption (plain-text) data, including your user names and passwords. It could also technically be your server’s private key (because that is used in the securing process) and/or your server’s certificate (which is also not something you should share).

The ability to retrieve a server’s private key is very bad because that private key could be used to decrypt all past, present and future traffic to the sever. The ability to retreive a server’s certificate is also bad because it gives the ability to impersonate that server.

This, coupled with the widespread use of OpenSSL, is why this bug is so terribly bad. Oh, and it gets worse…

Taking advantage of this vulnerability leaves no trace

What’s worse is that logging isn’t part of the Heartbeat extension. Why would it be? Keepalives happen all the time and generally do not represent transmission of any significant data. There’s no reason to take up value time accessing the physical disk or taking up storage space to record that kind of information.

Because there is no logging, there is no trace left when someone takes advantage of this vulnerability.

The code that introduced this bug has been part of OpenSSl for 2+ years. This means that any data you’ve communicated to servers with this bug since then has the potential to be compromised, but there’s no way to determine definitively if it was.

This is why most of the internet is collectively freaking out.

What do server administrators need to do?

Server (website) administrators need to, if they haven’t already:

  1. Determine whether or not their systems are affected by the bug. (test)
  2. Patch and/or upgrade affected systems. (This will require a restart)
  3. Revoke and reissue keys and certificates for affected systems.

Furthermore, I strongly recommend you enable Perfect forward secrecy to safeguard data in the event that a private key is compromised:

When an encrypted connection uses perfect forward secrecy, that means that the session keys the server generates are truly ephemeral, and even somebody with access to the secret key can’t later derive the relevant session key that would allow her to decrypt any particular HTTPS session. So intercepted encrypted data is protected from prying eyes long into the future, even if the website’s secret key is later compromised.

What do users (like me) need to do?

The most important thing regular users need to do is change your passwords on critical sites that were vulnerable (but only after they’ve been patched). Do you need to change all of your passwords everywhere? Probably not. Read You don’t need to change all your passwords for some good tips.

Additionally, if you’re not already using a password manager, I highly recommend LastPass, which is cross-platform and works on pretty much every device. Yesterday LastPass announced they are helping users to know which passwords they need to update and when it is safe to do so.

If you do end up trying LastPass, checkout my guide for setting it up with two-factor auth.

Further Reading

If you like visuals, check out this great video showing how the Heartbleed exploit works.

If you’re interested in learning more about networking, I highly recommend Ilya Grigorik‘s High Performance Browser Networking, which you can also read online for free.

If you want some additional technical details about Heartbleed (including actual code!) checkout these posts:

Oh, and you can listen to Kevin and I talk about Heartbleed on In Beta episode 96, “A Series of Mathy Things.”


Securing Your On-line Life with a Password Manager and Two-Factor Auth

The Internet was ablaze last week with discussion of the hacking of Mat Honan. For those not up to speed about what happened, hackers were able to use social engineering and weaknesses in the security policies of Apple and Amazon to obtain access to Mat’s on-line accounts and to reset all of his Apple devices. Scary stuff!

With this incident on everyone’s mind, I thought it would be a good idea to share the techniques I use to secure my on-line life. I encourage you to adopt these practices if you haven’t already.

Use A Password Manager

My favorite password manager is LastPass. It’s cross-platform and cross-browser. There is a free version and a very affordable premium version at $12/year.

Other options include KeePass and 1Password.

With LastPass, your data is stored online in an encrypted format. To access your information, you unlock your “vault” with a master password. On the desktop, LastPass isn’t a stand-alone program. Rather, you use it as a browser plugin. On mobile platforms there is a stand-alone program that includes an integrated web browser. Because your data is stored online, it is synchronized across and available from multiple computers. This is great if you use more than one system, which I do. LastPass also offers the ability to access your vault when you’re off-line (though two-factor auth is limited in this case).

LastPass allows you to securely store:

  • passwords for all your sites
  • secure notes, which you can use to store misc information like server logins, credit card and bank account info, passphrases and more
  • form data, including credit card information (makes online buying a snap)

It also provides a password generator.

Here’s an example of what it looks like to retrieve passwords in LastPass:

Free Image Hosting at www.ImageShack.us

And here’s how I login to sites that I have saved with LastPass:

Free Image Hosting at www.ImageShack.us

Using a password manager, be it LastPass, KeePass, 1Password or another solution, allows you to easily follow the best practices I outline below.

Use a Unique, Strong Password for Every Site

You should never re-use a password. Use a unique password for every account that you create everywhere. This limits a security compromise from spreading to one site to another.

Make sure you pick a strong password. Better yet, use a computer generated password rather than one you make up on your own. Many password managers, including the ones I have mentioned in this post, have a password generator built in. Use it!

Here’s LastPass’ generator:

Free Image Hosting at www.ImageShack.us

How Do I Remember All These Unique Passwords?

At this point you might be asking, “how will I remember all these difficult passwords?” You won’t! The only password you’ll need to remember is the master password for your password manager.

Stand-Alone Password Generators

Don’t like or want to use the built-in password generator? There are plenty of stand-alone options.

My favorite password generator is actually the one that ships with OSX. It’s a bit difficult to get to, however, because you have to open the keychain and then click on some additional buttons. However, this app will call the password generate dialog directly.

If you’re on Windows, there’s pwgen-win. If you’re on Linux, try apg or pwgen.

Don’t Use Real Information in Security Questions

Security questions are those additional questions you fill out when you set up web accounts, especially for on-line banking. Some examples:

  • childhood nickname
  • name of first pet
  • first school attended
  • place where you met your spouse
  • favorite sports team

Most of the security questions I’ve encountered are absolutely terrible in that answering them honestly does nothing to protect your account. Why? Because we live in the age of social networking and answers to these questions are almost always readily available to anyone who’s willing to spend a few minutes searching on Google.

The solution is to provide bogus answers. Favorite Sports Team? The Bangalore Bananas. Or xFLXw99X62ONsPFU. There’s no way someone can use social engineering to come up with answers like these (unless you post them online for some reason). In order for this strategy to work, don’t rely on your memory. Instead, use your password manager to save the security questions and answers just as you do with unique, strong passwords. LastPass makes this particularly easy because on any webpage with a form you can use the “Save All Entered Data” to capture your questions and answers.

Enable Two-Factor (or 2-Step) Authentication Wherever Possible

Two-factor authentication means that in order to login to a site, you need to provide two pieces of information instead of just your password. Most two-factor authentication schemes involve providing your password and a unique code generated by a separate program, usually on a physical device.

For example, when I log in to Google, I first login the usual way and am then prompted for a verification code:

Free Image Hosting at www.ImageShack.us

And then I open Google Authenticator on my phone in order to retrieve a special code:

Free Image Hosting at www.ImageShack.us

Enabling two-factor authentication adds an extra level of security because it means a hacker can’t login to your account even if they have your password. They’d also have to have the physical device that generates the second authentication factor.

In this post I’ll cover enabling and using two-factor authentication with Gmail and with LastPass.

Enabling Two-Factor Auth for Google

To enable two-factor authentication for your Google account:

  • Login to your account and navigate to your Account page.
  • Navigate to security settings.
  • Click ‘edit’ next to 2-step verification.
  • If you haven’t already verified you’re phone, you’ll need to do so now.
  • After this, 2-step verification will be enabled.

Free Image Hosting at www.ImageShack.us

You should now set how to receive your verification codes. You can enable one or more of the following methods:

  • Mobile application (Google Authenticator, for Android and iOS)
  • Backup phone (not your Google voice number)
  • Print backup codes (keep in your wallet or somewhere else safe)

Free Image Hosting at www.ImageShack.us

I recommend setting all three, especially if you have a smart-phone or tablet. The method I use most often is the mobile application.

When you select mobile application, you’ll see the following screen. Scan the QR code with your phone or table. You’ll then be given a key to enter into the form to verify your device.

Free Image Hosting at www.ImageShack.us

Note: You can install Google Authenticator on multiple devices, but you  must do so at the same time. If you wish to add a device later, you’ll need to turn off 2-step authentication and go through the whole process again. You do not need to do this in order to add another Google account to Authenticator, however.

Generating Application-Specific Passwords

What happens if you want to use an email client like Thunderbird, Mail.app or Outlook? Or a chat client with your gTalk? You still can, but you have to generated application-specific passwords. What this means is that for each application you would like to allow to access your mail or chat, you generate a password for. This password is revocable at any time should you loose control of that application (e.g. you loose the laptop on which it’s installed) or suspect that the password has somehow been compromised.

Free Image Hosting at www.ImageShack.us

Enabling Two-Factor Auth in LastPass

LastPass offers a few options for two-factor authentication:

  • fingerprint reader
  • grid authentication
  • Yubikey
  • Google Authenticator

I selected Yubikey. A Yubikey is a USB device that generates a unique, one-time password. Once you link a Yubikey to your LastPass account and enable two-factor authentication, you need to use your Yubikey along with your regular password each time you want to log in (although you can specific which computers are trusted and therefore do not require secondary authentication).

I bought 2 Yubikeys and an additional year of LastPass service for $50. Because you can associate your LastPass account with multiple Yubikeys, I have one for regular use and one for a backup in case I loose the first.

Here’s what it looks like when I log in to LastPass with Yubikey authentication enabled.

First I’m prompted like usual for my LastPass email and password:

Free Image Hosting at www.ImageShack.us

And then prompted from my OTP from Yubikey:

Free Image Hosting at www.ImageShack.us

Have a Recovery Email That is Not Easy to Guess and Keep it Private

Both Google and LastPass allow you to specify a recovery email address. I strongly recommend that you setup a second email account that is dissimilar to your regular, public email address, keep it private and use it as the recovery email for your critical accounts (like Google and LastPass). The reason for using a private, separate email is so that hackers are less able to guess your recovery email and be able to launch an attack against it.

Also, if you are uncomfortable having all your on-line eggs in one basket like I am, consider paying for a backup email account from a service like FastMail, HushMail or Pobox.

Change Important Passwords Periodically

You should change the passwords on your critical accounts on a regular basis. Quarterly is probably a good target. Even twice or once a year will be better than never. For best results, link it to some other deadline. Self-employed? Change your critical passwords when you send in your quarterly estimated taxes.

What are critical passwords? Your Google account and password manager, certainly. Probably also your on-line banking, too.

Check Access Logs Frequently

Most systems provide access logs that you are able to check. You should periodically examine this information for anything that seems strange. Look for connections that don’t match your usage because this could be a sign someone is accessing your account without your permission or knowledge.

To see your Google access logs, log in to Gmail, scroll down to the bottom of your inbox and look for “Last account activity.” Then click on details.

Free Image Hosting at www.ImageShack.us

You’ll see a screen like this where you can see which IP addresses have been connecting to your account:

Free Image Hosting at www.ImageShack.us

Make Regular Backups

The above steps are not a guarantee against your data being compromised. You should make sure you’re regularly backing up any data that’s important to you, including your password information.