Most of us associate secure internet and web services with encryption, that is the coding of data in such a way that only the recipient can decrypt it. But in a paradoxical way, coding of data so the recipient cannot recover the original data is even more important. There are now issues looming with that one-way process which are already causing Firefox and Google Chrome to report problems with many websites. These are only getting worse.

You may be familiar with the idea of a checksum or CRC, which is widely used to check that the contents of a file or packet of data are correct. These function as signatures for the file or data: if it gets corrupted, accidentally or deliberately, the checksum will change, and will no longer match that expected.

The problems with one-way encoding concern a specialised type of signature, created using a hashing technique, in this case SHA-1 and SHA-2. Their most crucial role here is with security certificates. When your browser tries to establish a secure connection with a site, it has to check its security certificate, which in turn relies on one-way encoding using hashing.

Old signatures used an old technique, SHA-1 (Secure Hashing Algorithm version 1), introduced back in 1995, which relies on a 160-bit hash value known as the message digest. When first used, it was not feasible for an attacker to ‘break’ a SHA-1 message digest so they could use it in an attack. Over the years, though, the cost and effort to accomplish that has fallen steadily, and is now less than $75,000.

SHA-2, which relies on a hash value of at least 224 bits (and more typically 256 or even 512 bits), was introduced in 2001, and is still considered to be secure against attack, at least by anyone other than a government security agency. So the logical step would be to replace all use of SHA-1 with SHA-2, so that we can sleep more easily at night. If only it were that simple.

First, when security certificates are issued, they come with SHA-1 or SHA-2 support. Although all certificates issued since 1 January 2016 are required to have SHA-2 support, SHA-1 certificates had still to be issued in 2016 because some critical systems could not yet be switched over to use SHA-2.

Security certificates cost money, and have defined lifetimes. Organisations with SHA-1 certificates which still have plenty of time to run are likely to choose to continue using them.

There are also still plenty of systems in use which lack SHA-2 support. Anyone using Windows XP prior to Service Pack 3 will be using a version of Microsoft Internet Explorer which won’t support SHA-2. Solutions have been developed so that those old systems can still receive SHA-1 certificates, while others get SHA-2 ones, but so far this ‘SHA-1 fallback’ has only been generally adopted by Facebook, Alibaba, and CloudFlare.

The worst problems come with security certificates which have to be embedded in hardware, such as credit card terminals. Replacing those certificates usually means replacing the hardware, which is costly and complicated, so is often delayed as long as possible.

The result is that a substantial number of servers and services still rely on SHA-1 certificates, and on SHA-1 for other purposes where it is no longer acceptably secure.

If you use Firefox or Google Chrome and they try to establish a secure connection using a SHA-1 certificate, they will already warn you of that. Google and Microsoft are being even more aggressive over switching to SHA-2: from 1 February 2017, just a few days from now, Chrome will refuse to connect with servers and services which only support SHA-1. Microsoft browsers follow suit two weeks later.

Macs use security certificates in plenty of other situations, including PGP, SSH, VPN, and most of all with app signatures. Apple has directed all developers to switch to using App Transport Security. This should ensure that all apps require secure connections using HTTPS and not HTTP, and that SHA-2 is used. However, this does not apply to apps which use low-level access to connect (such as using BSD sockets), which will be able to continue to use SHA-1. Apple is also unable to enforce such policy on apps which are provided outside its App Store, and in any case has postponed enforcing this on App Store apps.

Ironically, Gatekeeper’s code signing system still uses SHA-1 certificates issued by Apple. Although this is hardly likely to prove a vulnerability, it demonstrates how reluctant the industry is to switch to SHA-2.

You can inspect the security certificates stored on your Mac using Keychain Access: select a certificate and Get Info (Command-I) for it to see whether it uses SHA-1 or one of the SHA-2 variants with a message digest of 224 bits or more. Of course, certificates used to establish secure connections and for other temporary purposes are not recorded here, so you cannot generally use Keychain Access to discover which servers and services still use SHA-1.

Meanwhile Safari looks set to continue working happily with SHA-1 and SHA-2 security certificates. If you have discovered sites which Chrome and Firefox complain about – and will soon block – this makes Safari a valuable alternative. But, knowing that SHA-1 is vulnerable, you should also be asking yourself whether you should connect to those sites and services at all, or whether you want your browser to block them to guarantee better security.

As SHA-1 gradually fades into history, we’re left with a mess that should have been sorted out years ago. Be prepared from some glitches in the future, and don’t be surprised when antiquated servers and services suddenly stop working.