Ask your host whether the server ran an affected version of OpenSSL and when it was fixed. Then have the certificate reissued with a new key, revoke the old one, and only then change passwords.

A flaw underneath the padlock

On Monday a serious flaw was disclosed in OpenSSL, the free software that provides the encryption on a great many web and mail servers. It has been named Heartbleed.

Since then, owners of secure sites have been getting emails from their host or certificate seller, full of terms like private key and reissue.

Meanwhile the padlock in the browser looks exactly as it did last week. It says the connection is encrypted with your certificate's key, not that the software or the key is safe.

What the flaw allows

A secure connection can send a small message, called a heartbeat, to check that the other side is still there. The other side is meant to echo it back exactly.

The flawed versions did not check the length the sender claimed. A short heartbeat claiming to be long brought back up to 64 kilobytes of the server's memory, again and again, without any login.

That memory can hold the passwords and login cookies of people using the site, and the private key behind its certificate. Normal logs record nothing, so nobody can tell whether a server was read.

The flaw is in OpenSSL 1.0.1 to 1.0.1f, released from early 2012, and is fixed in 1.0.1g. Servers on older versions, or on other encryption software such as Microsoft's, were not affected.

Questions for your host

On most small business hosting, only the host can update OpenSSL. Ask it for written answers on these points:

Keep the reply. The date the server was fixed sets the timing for everything that follows.

Why the certificate may need reissuing

A certificate pairs your domain with a private key that should exist only on your server. Browsers show the padlock because only the holder of that key can complete the secure connection.

If the key was read from memory, someone holding it could pose as your site to people on a network they control, such as public wireless, and the padlock would still appear.

Since nobody can tell whether a key was taken, the safe course on an affected server is a new key, a reissued certificate and the old one revoked.

Getting it reissued

If the host sold you the certificate, ask it to handle the reissue. If you bought it elsewhere, a new key and signing request are made on the updated server and sent to the seller.

Most sellers reissue at no charge during the certificate's term. The order matters: a new key made before the server was updated could be read in exactly the same way.

To check the work, open the certificate details behind the padlock in the address bar. Its issue date normally falls after the day the server was fixed; if it does not, ask the seller to confirm the reissue.

Mail and the control panel

The same OpenSSL often protects the server's email connections and the control panel login. Email programs that connect securely, and webmail, sent their passwords through it.

Ask the host whether those services were updated and restarted too. A web server fixed on Monday does not mean the mail service was.

Passwords after the fix, not before

A password changed on an unfixed server passes through the same memory as the old one. Wait until the host confirms the update and the new certificate is installed.

Then change the passwords for the control panel, the site's administration area, email and file transfer, and anywhere one of them was reused. End every open session, so copied login cookies stop working.

For services you use elsewhere, such as online banking, wait until each says it was unaffected or has fixed its servers before changing anything there.

A worked example

A sneaker shop in a busy shopping district sells in the store and online, where customers keep accounts to follow limited releases and check out over a secure connection.

The owner read the host's notice on Tuesday and asked the questions above. The server had run an affected version and was updated on Monday night.

The certificate, bought separately two years ago, still had its old key. The developer made a new key on the updated server, the seller reissued the certificate, and the old one was revoked.

Only then did staff change every password and end all customer sessions. Customers with accounts got a short email explaining the flaw, what the shop had done, and that they should change their password.

Telling customers calmly

If customers log in to your site, they deserve a plain message once the fix is complete, not before. Say what the flaw was and that it affected software used by many sites.

Ask them to change their password, there and anywhere else they used it. Say what you did and when.

Do not claim that nothing was exposed, because nobody can know that, and do not suggest that something was.

The counter-case

A plain brochure site, with no certificate and no logins, has nothing to reissue, and its visitors have no passwords on it to change.

Even so, its server's control panel and webmail usually use secure connections, so those passwords may have passed through the flawed software. Change them once the host confirms the fix.

A server that never ran the flawed versions needs no reissue at all. For it, the host's answer in writing is the whole job.

From the update to the new passwords

  1. Ask the host whether the server was affected.
  2. Get the update date in writing.
  3. Have the certificate reissued with a new key.
  4. Revoke the old certificate once the new one works.
  5. Check the issue date in the certificate details.
  6. Change every password, then end open sessions.
  7. Tell customers who have accounts.

Step six depends on all the others. A new password set on a server that is still flawed, or behind a key that may be known, is no safer than the old one, so it waits.

If someone does get hold of a mailbox password, what to change first and how to reassure clients is covered in clients asking whether you are really stranded abroad.


Frequently asked questions

What is Heartbleed?

A flaw in OpenSSL, encryption software used on many web and mail servers. It let anyone read pieces of a server's memory, which can hold passwords and the certificate's private key.

Was my website affected?

Only if its server ran OpenSSL 1.0.1 to 1.0.1f. On most small business hosting only the host can say, so ask for the answer and the update date in writing.

Why does the certificate need reissuing?

Its private key may have been read from the server's memory, and nobody can tell. A new key, a reissued certificate and the old one revoked remove that risk.

Should I change my passwords right away?

Only after the host confirms the server is fixed and the new certificate is installed. A password changed earlier passes through the same flawed memory as the old one.

How can I tell the certificate was replaced?

Open the certificate details behind the padlock. Its issue date normally falls after the day your host fixed the server; if not, ask the seller to confirm the reissue.

Should customers be told?

If they log in to your site, yes, once the fix is complete. Say what happened and what you did, and ask them to change their password there and elsewhere.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Not sure whether your server was affected?

Forward us your host's notice, and we will check the server and certificate and list what still needs doing.

Start a Conversation