PCI 3.1 and the End of Old SSL for Card Payments

What was published yesterday

The PCI Security Standards Council, the body the major card brands set up to write security rules for anyone who accepts cards, published version 3.1 of its data security standard yesterday.

The headline change: SSL, and the early versions of TLS that replaced it, no longer count as strong cryptography, the standard's term for encryption good enough to protect card data.

New setups may not use them at all. Existing ones have until June 30, 2016 to retire them, and until then are expected to have a plan for doing so.

What follows is general information, not a compliance opinion. Your payment processor decides what your shop has to do.

SSL, TLS and the padlock

SSL and TLS are the protocols behind HTTPS and the padlock in the address bar. TLS replaced SSL, and has itself been revised: TLS 1.0 in 1999, 1.1 in 2006 and 1.2 in 2008.

When a browser connects to a server, the two agree on the newest version both support. Leaving old versions switched on means some connections still use them.

Worse, an attacker sitting between the two can sometimes push a connection down to weaker encryption that should no longer be in use. FREAK, disclosed last month, was a flaw of that kind.

SSL 3.0 has been considered broken since last fall, and many hosts have already switched it off.

Where a small shop uses it

• Your checkout pages, if card numbers are typed into them.
• Your server's connection to the payment gateway.
• A hosted payment page your provider runs for you.
• Card terminals at the counter, handled by their supplier.
• Staff logins to the shop's order screens.

The second is the one most owners never consider. When your shop sends a payment to the gateway, your server plays the part of the browser, and its age decides which versions it can speak.

Your server is also a client

Encryption libraries on servers set up before about 2012 often cannot use TLS 1.2 at all. A shop on such a server connects to its gateway with TLS 1.0, because that is the best it has.

Payment gateways must meet the same standard. As they switch off the old versions on their side, a shop that cannot speak TLS 1.2 will find its checkout failing on the day the gateway makes the change.

Nothing on the shop's own pages warns of this. The first sign is customers reporting that payment would not go through.

Gateways usually announce such dates by email to the account holder. Make sure those emails reach someone who reads them.

Your checkout pages

The other half is what your server accepts from customers' browsers.

Free online server tests take your address and report which versions of SSL and TLS the server allows, along with other weaknesses. Run one on the checkout's address and keep the result.

On shared hosting these settings belong to the host, not to you or your developer. Ask the host in writing which versions your account accepts, and when it plans to switch the early TLS versions off.

Customers on older computers

Switching off TLS 1.0 on a checkout today would shut out some customers.

Internet Explorer on Windows XP cannot use the newer versions at all, and Internet Explorer before version 11 has them switched off by default. Some older Android phones and Macs are limited in the same way.

The time before the date for existing setups is useful for exactly this: seeing who still connects the old way, and planning the change rather than springing it on customers.

A worked example

A sunglasses store in a beach town sells polarised and prescription-ready frames at its counter and through a small online store.

Its checkout, added in 2010, took card numbers on its own page and passed them to the gateway from the shop's server, which sat on an older hosting plan.

Last winter the payment provider emailed its merchants about retiring old encryption. The owner asked the host two questions: which versions the checkout accepted, and whether the server could reach the gateway using TLS 1.2.

The answers were that SSL 3.0 had been off since the fall, TLS 1.0 was still on, and no: the server's encryption library was too old for TLS 1.2.

The shop moved to a current server in March, placed test orders on real cards, and switched to the provider's hosted payment page, which took card entry off its own pages.

When version 3.1 arrived yesterday, the owner already had a one-page record of each connection.

If card numbers never touch your site

Many small shops send customers to the payment provider's own page to type in their card details. That keeps card data off the shop's server, and the provider has to meet version 3.1 on its side.

It does not take the shop out of the picture. Your pages lead customers to theirs, the annual self-assessment questionnaire still asks about your site, and your server may still talk to the provider in the background.

Ask the provider which versions its pages and its connections accept, and when that changes.

Write the plan down

A plan for a small shop can fit on one page.

List each connection that carries card data or leads to it, which versions it accepts today, who controls it, and the date each old version will be switched off.

Add the date each answer was checked and who gave it. When the processor asks, or when something stops working, that page is where the answers are.

The counter-case

A shop that sends every card payment through a provider's hosted page, on a current server and a current hosting plan, may find very little to do beyond confirming that and writing it down.

A business that takes payment only by invoice, cheque or Interac e-Transfer is not affected by this change at all.

For a shop taking cards on its own pages or from an older server, though, ask the questions now and plan to retire the old versions well before June 30, 2016.

Before June 30, 2016

1. Ask your payment provider about its TLS dates.
2. Ask your host which versions your server accepts.
3. Test your checkout pages with a free server check.
4. Confirm your server can connect using TLS 1.2.
5. Move off any server that cannot.
6. Write down each connection and its switch-off date.
7. Take questions to your processor, not to guesswork.

Step four is the one that can stop a checkout without warning. A server that cannot speak TLS 1.2 keeps working until the gateway changes, and then every payment fails at once.

The last step of a checkout can go wrong in other ways too, as covered in customers charged twice after a slow checkout.

Frequently asked questions

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.