System security is of paramount importance to our clients and a perennial area of investment and focus for all at FundApps. The advent of the Heartbleed bug, which was discovered in a widely used cryptography library called OpenSSL in early April, caused widespread attention and concern around the security of many services.

At FundApps we were unaffected by Heartbleed, but I wanted to take the opportunity to talk about transport layer security and how FundApps applies best practices in this area. We are used to seeing the padlock icon in our browser to indicate a secure connection - but what does this actually mean? When accessing a website using HTTPS, this relies on a cryptographic protocol known as Transport Layer Security (TLS) and it's predecessor Secure Sockets Layer (SSL). In the context of HTTPS, these are designed to ensure two things:

1. That you know whom you are communicating with and to provide protection against "man in the middle" attacks - when you think you are talking to Bob but in fact Mallet is intercepting your messages and potentially injecting new ones.
2. That your communications are encrypted, to protect against eavesdropping or tampering of a messages contents.

There are several moving parts that can affect exactly how successful we are in achieving these goals:

1. Implementation of an underlying library (such as OpenSSL, or SChannel on the Windows platform) that implements TLS
2. Security of the certificate authority responsible for issuing certificates and therefore assuring the identity of who we communicate with
3. Versions of the protocol that are in use (TLS 1.2 and 1.1 are significantly more secure than TLS 1.0 and SSL 3.0)
4. Which underlying encryption algorithms and key lengths are used
5. Web server configuration

So how do we address these?

#1 Heartbleed has illustrated that choosing a widely used and open source (so in theory open to inspection for such issues) library such as OpenSSL offers no guarantees of security. All you can do is ensure you are applying patches when vulnerabilities are discovered and mitigating any consequences of this (such as reissuing and revoking certificates). There are also other things we can do (such as Forward Secrecy) to limit the impact of such vulnerabilities (which I will cover in #4).

#2 Major reputable providers Comodo and GlobalSign have been hacked in the past, and this is one of the weaknesses of the current security infrastructure of the internet. In order to verify the identity of who we are talking to, we are dependent on a certificate authority making sufficient checks and only issuing a certificate to, say HSBC, when they know that the entity requesting it is in fact HSBC. As such, we must be vigilant and use certificate revocation to ensure that if these have been issued incorrectly we can rescind access.

#3 Not using any outdated ciphers and ensuring that the strongest possible algorithms are offered first to browsers that support them. For instance, TLS 1.2 should be enabled, and keys should be at least 2048 bits in length.

#4 Enabling forward secrecy. With the correct ciphers, we can ensure that a session key (a short term key used to encrypt your communication) derived from a long term key cannot be compromised if one of the long term keys is compromised in the future. This means that, for instance, if someone were to intercept and record all your encrypted traffic now, and crack your private long term key in a years time, they wouldn't be able to go back and read your old communications

#5 Enabling HTTP Strict Transport Security. The idea here is to stop man-in-the-middle attacks whereby the attacker switches a HTTPS connection to a plain HTTP connection. Visitors can see the connection is insecure, but there is no way of knowing that the connection should have been secure. By adding a HTTP Strict Transport header (which is remembered by the browser and stored for a specified period), then provided first communication with the server is not tampered with (by stripping out the header), the browser will prevent non-secure communication from then on.

Our infrastructure is also regularly scanned by external services such as SSL Labs for third party confirmation that we're doing our utmost to minimize the risks of security issues such as Heartbleed, and implement industry best practices.

Undoubtedly, as malicious attackers become more sophisticated, technology firms must continue to invest and ensure robust security protocols firmly underpin the architecture of their platforms. Here at FundApps we will continue by putting the security of client data at the forefront of everything that we do.