Security Update (Feb 2017)

Submitted by mathew on Fri, 17/02/2017 - 16:13

As you may have gathered from my previous blog posts, I'm keen to maintain my focus on security and I like to stay ahead of any potential problems.

This post concerns the security of the connection between the app (Easy Books or Easy Invoice) and the Online Sync service.

Communications between the apps and the service is only permitted over an encrypted connection, you may be aware of the "S" in HTTPS which stands for "secure". SSL is another term for this, although this was deprecated years ago in favour of a more general term TLS ("Transport Layer Security").

From June 2016, the Payment Card Industry (PCI) Security Standards Council has mandated strengthening encryption standards and to discontinue use of TLS 1.0 and SSL in secure credit card transactions. We use a third party payment company called Fastspring to handle these, so while we are not required to be PCI compliant ourselves, it seems sensible to follow this lead in our own online services.

So on 24 Feb 2017, all communications will be secured by TLS version 1.2 and it will no longer be possible to connect using older protocols.

Who does this affect?

Anyone using an old copy of Easy Books on OS X 10.8 "Mountain Lion" or earlier, or on iOS 5 or earlier. These devices do not understand the new TLS 1.2 protocol.

When running Easy Books, you may see a flashing yellow status dot shown next to Online Syncing in the sidebar. Opening this screen reveals the error message "An SSL error has occurred and a secure connection to the server cannot be made". If you see this message, your Mac is unable to connect to the sync service.

There are twenty people currently using Easy Books on an old Mac and I have written to everyone affected.

This Wikipedia page has a summary of browser support for TLS.

More technical information

Ideally we want the encryption to be completely un-crackable, making the communications completely private between the two endpoints. No machines along the communication path should be able to decrypt whatever is being passed, receiving the encrypted data should have no value. A few years ago the Internet in general moved to PFS ("Perfect Forward Secrecy"), as we did in Feb 2014. This means past communications is not compromised if a server's private key is exposed in the future. All communication is carried out using an ephemeral key, which is known to the two endpoints and destroyed after the connection has been closed.

No encryption is un-crackable though. It's really just a question of time. Security is maintained by how long it would take powerful computers to crack the encryption using brute force, trying every possible encryption key. What we need to watch out for is any possible shortcut to this brute force attack. If there are, this might reduce the time required from billions of years down to something more reasonable: within our lifetime.

Vulnerabilities in SSL / TLS tend to be largely theoretical, by which I mean exploiting the vulnerability might require many things to come together at once. For example, you might be vulnerable to eavesdropping only when using an open WiFi hotspot. But there are also implementation errors, which lead to timing attacks and some high profile attacks such as POODLE, BEAST and HEARTBLEED which cause concern.

I think the time has come to drop support for older protocols and ciphers and move with the times.