Check every server that uses your certificate, including mail servers, and have SSLv2 switched off on all of them. A website can be exposed through another machine that shares its key.

What was disclosed yesterday

Yesterday a group of researchers disclosed DROWN, a way to decrypt secure connections to a server that is set up correctly, by way of a different server that is not.

The weak server is one that still accepts SSLv2, a version of the protocol behind secure connections that was replaced twenty years ago and should have been switched off long since.

The two servers only need one thing in common: the same private key, which is exactly what they share when one certificate is installed on both.

A website can be exposed without ever having spoken SSLv2 itself. That is what makes this one worth an hour of your week.

Visitors cannot protect themselves from it, whatever browser they use. Only whoever runs the servers can fix it.

How an old server exposes a modern one

Every certificate comes with a private key, the secret a server uses to prove who it is and to set up an encrypted connection.

An attacker who has recorded encrypted traffic to your website can send a large number of specially built connection attempts to the old server. Because of how SSLv2 works, its answers leak enough to decrypt the recorded sessions.

The attacker does not learn the key itself. What they can read is whatever passed through those sessions: logins, form submissions, email.

And if the website's own server still accepts SSLv2, it is exposed directly, with no second machine involved.

Against some older server software that has not been updated, the attack is much quicker than that description suggests.

Where the old servers hide

The last ties the rest together. A wildcard covers every name under a domain, so it tends to be installed everywhere, and one forgotten machine exposes every connection that uses its key.

Testing for it

The researchers published an online check that takes a domain name, and free online server tests already show whether a server accepts SSLv2.

Those tests look at one name and usually one service. A website test checks the website. It does not check a mail server at another address, which is exactly where the problem tends to be.

So test every name your certificate covers, and ask whoever runs your mail to check the secure ports used for sending and collecting mail, not just the web.

A clean result for the website alone proves less than it appears to.

Asking the host to switch old protocols off

Most small business websites sit on a host's servers, and those settings are the host's to change. Ask in writing.

Ask whether SSLv2 and SSLv3 are switched off for every service on the server, mail included. SSLv3, the next version up, was found to be weak in 2014 and has no place on a server either.

Ask whether the server's encryption software is up to date. Updates released alongside the disclosure remove SSLv2 support by default.

And ask whether your certificate's key is installed anywhere else they manage. The answer should be a list, not a reassurance.

A worked example

A freight forwarder with a dozen staff runs its website on a hosting plan and its email on a server in the office, set up by a contractor several years ago.

When the website moved to HTTPS last year, the contractor bought a wildcard for the company's domain and installed it on both, so staff phones would stop showing a warning every time they collected mail.

Yesterday an online check flagged the company's domain. The website's own server had never offered SSLv2. The mail server still did, because its settings dated from the day it was installed.

Because the two shared a key, the website's connections were exposed through the mail server, including the quote form where customers enter shipment details and contact information.

The contractor switched off SSLv2 and SSLv3 on the mail server, updated its encryption software and ran the check again on both names. The website itself needed no change.

The forwarder also wrote down every machine holding the certificate, and decided the next renewal would give the website and the mail server separate keys.

One key, one place

The convenience of one certificate everywhere is what DROWN exploits. Separate certificates, or at least separate keys, mean a weak machine exposes only itself.

When a certificate is renewed, generate a new key rather than reusing the old one. Many renewals quietly carry forward a key created years earlier.

If you cannot be sure SSLv2 is off on every machine that ever held the key, replace the certificate with one on a fresh key. Otherwise, the researchers say, a new certificate is not needed.

Keep a list of where certificates live

One list does several jobs: which certificates the business owns, which names each covers, where each is installed, and when each expires.

It is the list that answered January's question about older certificates, and it answers this one.

Note who installed each one and who can change that server's settings. The person who can switch off SSLv2 is the one you will need to call.

The list belongs with whoever renews the certificates, not in the memory of a contractor who set them up once.

The counter-case

Many small business sites were never exposed. Servers set up in recent years mostly shipped with SSLv2 off, and a site on a well-run host, with its certificate on one server, has little to fear from this.

Nor is DROWN a reason to panic about past email. It needs an attacker who recorded your traffic and then did considerable work on it.

But nobody can tell from the website alone. Check every server that uses your key, and make sure SSLv2 is off on all of them.

Start with the list

  1. List every server that uses your certificate.
  2. Test each name, including the mail server.
  3. Ask your host to confirm SSLv2 and SSLv3 are off.
  4. Update the encryption software on servers you run.
  5. Stop sharing one key across machines.
  6. Use a fresh key at the next renewal.
  7. Keep the list with the renewal dates.

Step one is the one everything depends on. The attack comes through the machine nobody remembered, and only a list makes sure it gets tested.

Why that certificate list was first worth making is covered in certificates signed with SHA-1 are no longer issued.

Frequently asked questions

What is the DROWN attack?

A weakness disclosed yesterday that lets an attacker decrypt secure connections to a modern server by using another server that still accepts SSLv2 and shares the same key.

Why does an old mail server matter?

If it holds the same certificate and key as the website and still accepts SSLv2, it can be used to decrypt the website's recorded connections.

Does my website need a new certificate?

Usually not, since the attacker never learns the key. Replace it with one on a fresh key only if you cannot confirm SSLv2 is off everywhere it was installed.

How can I test for DROWN?

Use the researchers' online check or a free server test for each name your certificate covers, and have the mail server's secure ports checked separately.

What should I ask the host to confirm?

Whether SSLv2 and SSLv3 are off for every service including mail, whether the encryption software is up to date, and where else your key is installed.

Is a site on shared hosting at risk?

Less often, if the host keeps its servers current and your certificate sits on one server. Ask anyway, because those settings are the host's to change.

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.

One certificate on several servers?

Send us your domain. We will test every name it covers, mail included, and tell you what still accepts SSLv2.

Start a Conversation