New features to keep your FastMail account even more secure

[dextron]

Hi there!
Who can explain, what is the reason of use this provider for personal use?
At present this provider still support weak cipher SSLv3 https://ssl-tools.net/mailservers/fastmail.com
"Security e-mail provider"(c) very funny, eah. May be they are provide support DANE/TLSA and DNSSEC? No? Or, may be provider can encrypt all incoming e-mail with OpenPGP? No? Or may be that data centers are located it adequate offshore countries? No again? And is it better than Google, Microsoft, Yahoo and other ********? If I understand correctly, I've to pay 30$ (btw, without my own domain) just for the fact that these guys promise not to read my letters and do not show any ads? Ok, thanks, that's good news. And yes, by the way. Has anyone seen transparency report or warrant canary from this service, which is under the jurisdiction of Five Eyes countries?
Thanks.

[ChinaLamb]

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.

Secure access to mail
We mandate all connections to our servers use Transport Layer Security (TLS) and Secure Sockets Layer (SSL) encryption, both for webmail and IMAP/POP/SMTP email client access. This prevents eavesdropping, tampering, and message forgery on any communication between your computer or phone and our servers.

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 webpages. 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.

Privacy: Image loading
When accessing your email through our web interface (ie: not via desktop or device clients), we protect your privacy by fetching all referenced images through our servers. This prevents the owner of the image from being sent additional information about you such as your internet address (which reveals your rough location), browser information and sometimes even tracking cookies.

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).

The only way to ensure end-to-end security with email is to use email encryption software such as Pretty Good Privacy (PGP) or Secure/Multipurpose Internet mail Extensions (S/MIME). Both of these systems require the creation of certificates, run on your computer, and are attached to your email client to encrypt/decrypt messages.

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

[dextron]

ChinaLamb
You know, after your copy-paste https://www.fastmail.com/help/ourservice/security.html (which I studied for a long time), I do not understand, why I would have become a client of this service, and how it differs from dozens of others. I do not see any differences. But no, it seems to see. They take the money for that elsewhere give for free. IMHO.

[ChinaLamb]

Originally Posted by dextron

ChinaLamb
You know, after your copy-paste https://www.fastmail.com/help/ourservice/security.html (which I studied for a long time), I do not understand, why I would have become a client of this service, and how it differs from dozens of others. I do not see any differences. But no, it seems to see. They take the money for that elsewhere give for free. IMHO.

If you want to understand about security, you need to understand that post. It is the entire reason this service is different than others.

[dgcom]

Originally Posted by ChinaLamb

If you want to understand about security, you need to understand that post. It is the entire reason this service is different than others.

I understand security. And I know, that using SSLv3 is NOT SECURE, so that's a very valid point made - despite your copy/pasting, Fastmail SMTP servers are failing behind on security.

This part:

Secure access to mail
We mandate all connections to our servers use Transport Layer Security (TLS) and Secure Sockets Layer (SSL) encryption, both for webmail and IMAP/POP/SMTP email client access. This prevents eavesdropping, tampering, and message forgery on any communication between your computer or phone and our servers.

Is actually wrong - use of SSLv3 does NOT prevent "eavesdropping, tampering, and message forgery" anymore.

[ChinaLamb]

Originally Posted by dgcom

Is actually wrong - use of SSLv3 does NOT prevent "eavesdropping, tampering, and message forgery" anymore.

Incorrect. Unpatched SSLv3 does not protect. Patched SSLv3 DOES protect. Check out specifications for SSL updates.

[dgcom]

Originally Posted by ChinaLamb

Incorrect. Unpatched SSLv3 does not protect. Patched SSLv3 DOES protect. Check out specifications for SSL updates.

I am aware of what the issue is. But I don't think you understand it - it is only good if BOTH sides are patched, which means that you can use SSLv3 if you control client and server - which is not the case here.

As it happened for SSLv2, recently Google engineers pointed out that SSLv3 is broken (with an exploitation technique known as POODLE) and should not be used any longer. There is a patch, but it does not mitigate the issue completely as it will work only if both sides of the connection have been patched.

http://disablessl3.com/

Also, it seems that Fastmail supports week ciphers...

So the point is - if Fastmail claims to be on the top of the security, their servers should be NO WORSE than competitors, but that seems to be not the case currently.

[ChinaLamb]

Originally Posted by dgcom

I am aware of what the issue is. But I don't think you understand it - it is only good if BOTH sides are patched, which means that you can use SSLv3 if you control client and server - which is not the case here.


http://disablessl3.com/

Also, it seems that Fastmail supports week ciphers...

So the point is - if Fastmail claims to be on the top of the security, their servers should be NO WORSE than competitors, but that seems to be not the case currently.

Browsers have been patched for that vulnerability since mid 2014, Fastmail's servers are also patched. So I don't see what the problem is with SSLv3. Unless somehow someone chooses to use an unpatched browser, which may not even work.

[dgcom]

Browsers? Looks like you didn't even look at the link provided by dextron - it is about SMTP.
And even if both sides are patched, you still support weak ciphers.

And I repeat - comparison to competitors is what counts and SSL tests are not in FastMail favor right now.

[ChinaLamb]

Originally Posted by dgcom

Browsers? Looks like you didn't even look at the link provided by dextron - it is about SMTP.
And even if both sides are patched, you still support weak ciphers.

And I repeat - comparison to competitors is what counts and SSL tests are not in FastMail favor right now.

You do like to be derogatory in your posts, don't you? You are not a nice person to talk to.

Patched SSLv3 is the standard right now, along with TLS1.2. Google is the one who brought much of the issues with POODLE to light, and guess what, Google still uses patched SSLv3 for all their certificates. Again, the browsers out there are patched, as are all clients I know of. Check the banking sites, all other sites that claim to have the tightest security on the web, their certificates are patched SSLv3. Any admin who is worth their pay has patched their servers.

SHA256 (SHA-2) is the standard right now, endorsed by NIST, and is considered secure, and us the most used standard for secure signing.

Fastmail uses RSA2048 bit encryption which is, yes, insecure. Anyone with a powerful computer could easily crack it in 6.4 quadrillion years.

You seem to have an axe to grind on this, and are trying to make a point out of nothing, so I'm bowing out of this conversation.

Good bye.

[dgcom]

Originally Posted by ChinaLamb

You do like to be derogatory in your posts, don't you? You are not a nice person to talk to.

Sorry if I offended anyone, but I really don't like people feeding me BS...

Originally Posted by ChinaLamb

Patched SSLv3 is the standard right now, along with TLS1.2. Google is the one who brought much of the issues with POODLE to light, and guess what, Google still uses patched SSLv3 for all their certificates.

"Using SSLv3 for certificates"? What do you mean? How do you use _protocol_ for _certificate_? You either meant something different or don't really know what you are talking about, sorry.

Originally Posted by ChinaLamb

Again, the browsers out there are patched, as are all clients I know of. Check the banking sites, all other sites that claim to have the tightest security on the web, their certificates are patched SSLv3. Any admin who is worth their pay has patched their servers.

SHA256 (SHA-2) is the standard right now, endorsed by NIST, and is considered secure, and us the most used standard for secure signing.

We are not talking about certificates here. We are talking about protocols and ciphers, used by those protocols... And Fastmail SMTP server uses two weak ciphers - ECDHE_RSA_WITH_RC4_128_SHA and RSA_WITH_RC4_128_SHA, which "Any admin who is worth their pay" already removed from their endpoints.

Originally Posted by ChinaLamb

Fastmail uses RSA2048 bit encryption which is, yes, insecure. Anyone with a powerful computer could easily crack it in 6.4 quadrillion years.

You seem to have an axe to grind on this, and are trying to make a point out of nothing, so I'm bowing out of this conversation.

Good bye.

RSA2048 is NOT an "encryption"... This is just a _number_, read it up, may be on wiki, it is interesting...

No, I do not have an axe. I just don't like when people throw around terms and phrases they have no idea about or post some marketing blurb in response to legitimate question on security.

Again and again, compare:
https://ssl-tools.net/mailservers/fastmail.com
https://ssl-tools.net/mailservers/gmail.com
https://ssl-tools.net/mailservers/outlook.com
https://ssl-tools.net/mailservers/yahoo.com

Even Yahoo is better than FastMail!!!

Well, I guess, as you said - FastMail admins are not worth their pay, since they didn't configure their mail server to the current industry standard...

And this is sad and I'll tell why it is not good idea to keep SSLv3 for SMTP - if, for other protocols, clients at least can control the software they are using, but for SMTP, they often cannot - people don't host their own SMTP servers at home, they use provider. If that provider is not configured correct, any communication between that said provider and FastMail SMTP server can be affected by the attack, discovered by Google...

[brong]

Originally Posted by dgcom

Browsers? Looks like you didn't even look at the link provided by dextron - it is about SMTP.
And even if both sides are patched, you still support weak ciphers.

And I repeat - comparison to competitors is what counts and SSL tests are not in FastMail favor right now.

The fallback for failure to negotiate SSL/TLS for browsers is that the connection doesn't happen, and the user gets an error and can do something about it.

The fallback for failure to negotiate opportunistic TLS for SMTP is that the sender falls back to cleartext. An encryption that's breakable by a nation state is still "safer" than no encryption at all.

An active attacker which can advertise whatever it likes, so what we offer makes no difference there.

So we have opted for maximum likelyhood of negotiating _something_ with senders, which is different from browsers where the connection is direct from our servers to the end user, and encrypting the round trip is much more more valuable.

[dgcom]

The fallback for failure to negotiate opportunistic TLS for SMTP is that the sender falls back to cleartext.

Not always true. STARTTLS is only attempted if server supports it, and if it does, I client can make sure that it either goes through or fails completely (ex. message: "451 Remote connection is failed in STARTTLS").

I've been hosting medium-sized SMTP setup for several years up until couple of years ago and seen quite a number of different behaviors...

An active attacker which can advertise whatever it likes, so what we offer makes no difference there.

In other words - "Do not care if SMTP is encrypted or not"?
Yes, it is possible to do MIM for SMTP and disable encryption completely. But it does not mean that industry recommendations should be ignored.

In the coming months, we hope to remove support for SSL 3.0 completely from our client products.

Why would Google say all this if they came up with a patch?
Probably because:

SSL3.0 [RFC6101] is an obsolete and insecure protocol.

The only thing which the POODLE patch does is to make sure that protocol downgrade is intentional. It does NOT make SSL 3.0 anymore secure. As long as SSLv3 is supported by server, there will be a client connecting to it - and susceptible to decryption. Not supporting SSLv3 means client will get an error and can do something about it. Allowing SSLv3 means user will never know that his connection encryption is weak.

So we have opted for maximum likelyhood of negotiating _something_ with senders, which is different from browsers where the connection is direct from our servers to the end user, and encrypting the round trip is much more more valuable.

You are technically correct here, and I understand this. And I wouldn't have an issue if everyone else would have been doing the same - but they are not. And people can easily see that when comparing email provides.
And that does not go well with that marketing blurb posted earlier, because we can see that the following is no longer valid:

We mandate all connections to our servers use Transport Layer Security (TLS) and Secure Sockets Layer (SSL) encryption, both for webmail and IMAP/POP/SMTP email client access. This prevents eavesdropping, tampering, and message forgery on any communication between your computer or phone and our servers.

Because if SSLv3 with weak cipher is negotiated, connection can be eavesdropped.
Moreover, allowing fallback from secure SMTP to clear text is not technically "...mandate all connections..."
But that's marketing, we can ignore that

P.S.
Sorry for loading this topic with the detailed discussion. Years working with SSL taught me that majority of people (even those, who are responsible for security) have no real understanding how it works and what are the implications of specific configurations. As long as you don't control both sides of connection yourself or the other side gives some doubt in understanding security - any connection should be considered untrusted. In our case the best solution is to encrypt the body of the message and not rely on the transport layer. And change passwords more often and use MFA.

[BritTim]

This is an interesting discussion. One thing: it is important when discussing SMTP to distinguish client to Fastmail servers from Fastmail servers to/from other mail servers. In the former case, we can realistically enforce strong encryption (though there are howls of protest from some when their favorite mail client stops working). When Fastmail is using opportunistic encryption for transfer of messages between itself and other mail providers, there are several points to make

• Deciding not to accept messages from other mail providers because they are not sending it securely is a serious matter
• Failing to transmit emails on to the MX servers of other mail providers because they do not have strong encryption implies dropping messages that have already been accepted with a message like "your recipient is using a mail provider with encryption standards we do not like; message dropped". Good luck with that in the real world.
• As a practical matter, although there are proposals about how the issue could be fixed, there is no way currently of protecting against MitM attacks in these server to server communications. We can verify that a certificate is provided and encrypt accordingly, but we cannot know if that certificate really belongs to the correspondent server. That being so, arguing about whether a nation state could eavesdrop on the message transfer because of outdated ciphers is missing the point.

[brong]

Thanks BritTim for clarifying that. It's a very common error to conflate server to server SMTP with "SUBMISSION" (RFC6409) and imagine that we treat them the same. MX lookups, which is what that online tool mentioned above do, will only find the server to server hosts.

I would point out that we're not the only people who still allow plaintext SMTP between internet hosts:

brong@wot:~$ telnet gmail-smtp-in.l.google.com 25
Trying 64.233.188.26...
Connected to gmail-smtp-in.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP w4si22030569pfb.193 - gsmtp
HELO home.brong.net
250 mx.google.com at your service
MAIL FROM:<XXX>
250 2.1.0 OK w4si22030569pfb.193 - gsmtp
RCPT TO:<YYY>
250 2.1.5 OK w4si22030569pfb.193 - gsmtp
DATA
354 Go ahead w4si22030569pfb.193 - gsmtp
Subject: test email via SMTP

body
.
421-4.7.0 [101.167.44.245 15] Our system has detected that this message is
421-4.7.0 suspicious due to the very low reputation of the sending IP address.
421-4.7.0 To protect our users from spam, mail sent from your IP address has
421-4.7.0 been temporarily rate limited. Please visit
421 4.7.0 https://support.google.com/mail/answer/188131 for more information. w4si22030569pfb.193 - gsmtp
Connection closed by foreign host.

...

Obviously if I'd actually figured out my reverse DNS and added the normal headers used by real email, that might have stood a chance of passing their spam checks - but they will definitely accept non-encrypted SMTP sessions.

What we don't do, as pointed out in our marketing materials, is allow unencrypted submission, or pop3, or imap, or web access from clients. And those services are protected with a more limited list of algorithms:

https://www.ssllabs.com/ssltest/anal...d=fastmail.com

Sadly ssl labs don't appear to have the option to test other protocols than HTTP yet, though apparently they're working on it.

https://community.qualys.com/thread/12348

The most recent change on our SSL cipher list was made quite recently:

Date: Thu Sep 22 20:32:10 2016 -0400

OpenSSL: Add DES-CBC3-SHA back into ciphers list ref 1.0.2i update

So we do consider the exact format of this field quite frequently.