Most of our financial and personal transactions should be protected by secure Internet connections. A year on, how has the Heartbleed bug changed this?

You may recall that in April 2014, we were advised to change all our online passwords because of the Heartbleed security flaw. Can you now recall whether you did, or whether it has changed your approach to online security at all?

Heartbleed and related bugs struck when your browser used the Secure Sockets Layer (SSL) to establish a secure HTTP (HTTPS) connection with a remote server, such as when logging on to a service.

Your browser asks the website server to identify itself using a security certificate, through a complex series of exchanges. The server sends the site’s certificate, and your browser should check its validity. If that succeeds, your browser informs the server that it is happy to continue, completing the ‘handshake’ required to switch over to SSL. Sensitive information is then transferred using HTTPS to the server, encrypted using the key provided in the security certificate.

In fact SSL has long been replaced by its successor, Transport Layer Security (TLS), causing great confusion over nomenclature and version numbering. SSL 3.1 is equivalent to TLS 1.0, and the current TLS 1.2, defined in 2008, equates to SSL 3.3. SSL 2.0 and 3.0 (predating TLS 1.0) are widely recognised as suffering some severe security weaknesses, and some browsers may refuse to operate using those versions of the protocol.

Mechanism

A security certificate consists of a public key and the information required to identify its owner. The public key is part of a specially generated key pair, of which the owner keeps the private key a secret. When a certificate is used as part of an encryption protocol, the public key is used to encrypt all data that need to be sent securely from client to server, and only the private key will enable decryption.

When a secure method of encryption is used, this should guarantee that no third party can eavesdrop and decrypt the sensitive information. Similarly, a spoof site that tries to use a stolen certificate from a genuine site only has access to the public key, so cannot decrypt the sensitive data sent to the site using SSL.

Security certificates are issued by a Certificate Authority according to a chain: the Authority has a Root certificate which they sign themselves; they then issue certificates that can be traced back to that Root certificate. At the end of the chain, a ‘leaf’, your security certificate can be traced back to intermediates issued by the Authority, thus to the Root. If at any stage in that chain a certificate has expired or is not valid, then it invalidates all the security certificates from there out to the leaf.

Exploiting the bug

Earlier vulnerabilities in OS X and iOS could have allowed your browser to be tricked into establishing HTTPS with a bogus website, which did not have a valid certificate, because of simple errors in the handshake procedure to negotiate SSL.

Heartbleed was potentially much more serious, as a bug in the code of certain versions of OpenSSL enabled hackers to read memory contents, which could in turn reveal passwords (as happened to Mumsnet and others) and more.

At worst, a vulnerable server could (still) be attacked and yield its private keys, allowing the hackers to establish bogus sites which could then steal your personal details, such as payment card information. As no-one knows which sites may have been compromised, the simple answer was to recommend changing all passwords; however if you did so for sites that were still vulnerable to Heartbleed there would be no benefit until they had been updated and repaired. Thankfully this time OS X, iOS, and major browsers were not directly affected, although some individual apps were still vulnerable.

A month after Heartbleed had been made public, less than half of affected websites had reissued security certificates, and some of those reused private keys which could already have been compromised. No one knows how many remain vulnerable.

Relatively few individuals seems to have suffered loss of their personal data as a result of Heartbleed. Some 900 Canadians suffered theft of their social security numbers from the Canada Revenue Agency, Mumsnet had ‘several’ user accounts hacked, and a large US hospital chain had compromised confidentiality of 4.5 million patient records following theft of security keys. However the latter was not disclosed for 4 months.

Checking security certificates

Security certificates are central to SSL and HTTPS, as Heartbleed has made painfully clear. Root certificates trusted by OS X 10.10 are listed here, those for iOS 8 here, and individual apps at their own support sites; for example Firefox’s are given here.

You can compare standard certificate listings against those of your Mac; for OS X these are accessed using Keychain Access: select the Certificates category, and you will find root certificates listed in the System Roots keychain, for example. Double-click on the listed certificate entry to see further information about it.

Obtaining security certificates

You can always issue your own security certificate; the easy way uses the Certificate Assistant, accessed through the Keychain Access app menu. An alternative is the Terminal command
openssl req -new -newkey rsa:2048 -keyout mykey.key -nodes -out mycsr.csr
However without the external validity provided by a valid Root certificate, it will be of limited use.

Major vendors, or Certificate Authorities, include Symantec’s VeriSign, Entrust, Go Daddy , and Comodo. If you want to authenticate outgoing email messages using Secure MIME (S/MIME), prices are low, but commercial uses such as SSL certification for a website, allowing it to offer HTTPS connections, are considerably more expensive, as is the full protection required to support online credit card transactions.

dylib hijacking – a new twist

Apps, their updates, and anything containing executable code, are now vulnerable to a new risk, of dylib hijacking. Although not entirely free of risk, if you only download these over secure connections from trusted sites, and using the App Store and similar secure services, you should remain at very low risk. Full details are here and in the linked articles from there.

Note though that the security of those services is completely reliant on the security of SSL/TLS. If it were to become compromised again, as it did during the height of the Heartbleed problem, then that would be a very serious problem.

Updated from the original, which was published in MacUser vol 30 issue 07, 2014.