How FastMail provides a secure service

We have a great responsibility at FastMail to keep your email secure. We continually review our code and processes for potential vulnerabilities and we take new measures wherever possible to further secure your data. On this page we list some of the core things we do to maintain security.

We have full support for Perfect Forward Secrecy (PFS) with our encrypted connections, which ensures that even if we were somehow compromised in the future, no previous communication could be decrypted. All connections in supporting browsers have been protected by PFS since July 2012.

A Strict Transport Security header is sent with all of our web pages. This tells all modern browsers to only connect to us over an encrypted connection, even if you have a bookmark, click a link or type a URL to an insecure page at our site.

Encrypted sending/receiving

Whenever you send a message to someone outside of FastMail we have to send it across the open internet. Since January 2010 we have fully encrypted all connections between us and the receiving server whenever the other server supports it, preventing passive eavesdropping, tampering or forgery. Similarly, we have accepted encrypted connections for mail delivery to our servers since April 2009, and we encourage all servers connecting to us to use it.

Content security policy

Within our web interface we set a Content Security Policy header, which ensures that only scripts we've written can be run. This means that a potentially-malicious email that somehow managed to slip through our filters would still not be able to do anything dangerous.

We use isolated domains to separate out untrusted content from the pages we generate. For example, when you open an attachment, it opens at fastmailusercontent.com rather than fastmail.com. Thanks to browser cross-origin security restrictions, this means that a rogue attachment can never access any of your data.

Similarly, user websites are hosted on subdomains of user.fm, keeping them isolated from our site as well.

We only allow necessary communications

Many unexpected forms of attack come from failing to close potential vulnerabilities, including database port access, SSH port access, and so forth. We use kernel-level firewalling to only allow connections to the services provided by each machine.

We keep track of software updates

Software contains bugs. We track the software we use and any security vulnerabilities, and upgrade as soon as an issue is reported.

We use software systems that take security seriously

We use Debian as our operating system, because they take their security responsibilities and updates seriously. In most cases, an update for a security problem will be available within hours of the original report.

Physical location security

Our main servers are located at New York Internet (NYI) in New York City, USA. Their facility is a high security, video monitored location; with backup power, air conditioning, fire systems, 24x7x365 monitoring, and onsite technical support. As their website notes:

Data Center security is a top priority for NYI. We have taken extreme care to install the utmost security so that our customers know that their data is safe. Our Data Centers are located at heavily protected buildings where the security personnel are on guard 24x7. Other security features include biometric fingerprint readers on door locks, strategically placed cameras and motion detection, [and] doors equipped with alarm systems.

NYI does a whole lot more to ensure security, including their hardware, best-practices, and routines. You can read all about them on their homepage.

Bug bounty

We run a tight ship, but we're only human and humans can make mistakes. That's why we run a bug bounty program to encourage responsible disclosure of security issues and to reward security researchers who take the time to help us keep FastMail safe.

Limitations

While communication between your computer and our servers is encrypted, any email that you send to another server may have to pass over the internet in an unencrypted form (although we encrypt it wherever possible).

Providing secure end-to-end encryption via webmail is impossible. There are basically two options, both flawed:

Keep a private key on the server and encrypt email on the server

Although all traffic between the server and client may be encrypted via SSL, and then the email itself is encrypted on the server before being sent to the world, the unencrypted email is still available on the server between the SSL and encryption stages.

Use Java or JavaScript to encrypt email in the browser

Because the script has to run on the user's browser, you could look at the code to see it's secure. In reality, no one would ever do that. In addition, this method can't prevent someone using malicious scripts to send encrypted messages back to the server, as well as the encryption key, for the server to decrypt.

Famously, Hushmail, which allows you to use both of these options, admitted that the U.S. government compelled them to turn over the unencrypted emails of a number of users.

Their contention on how secure they are then relates to what it requires to get a court order. In a Wired article, Hushmail stated:

All Hushmail users agree to our terms of service, which state that Hushmail is not to be used for illegal activity. However, when using Hushmail, users can be assured that no access to data, including server logs, etc., will be granted without a specific court order.

A similar requirement applies to FastMail, as our Privacy Policy states. We won't release any data without the required legal authorisation from an Australian court. As an Australian company, we do not respond to US court orders.