|
FastMail Forum All posts relating to FastMail.FM should go here: suggestions, comments, requests for help, complaints, technical issues etc. |
|
Thread Tools |
14 Oct 2016, 07:48 PM | #286 |
Junior Member
Join Date: Oct 2016
Posts: 4
|
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. |
14 Oct 2016, 09:03 PM | #287 |
The "e" in e-mail
Join Date: Dec 2004
Location: a virtually impossible but finitely improbable position
Posts: 2,320
|
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 |
14 Oct 2016, 10:27 PM | #288 |
Junior Member
Join Date: Oct 2016
Posts: 4
|
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. |
14 Oct 2016, 10:58 PM | #289 | |
The "e" in e-mail
Join Date: Dec 2004
Location: a virtually impossible but finitely improbable position
Posts: 2,320
|
Quote:
|
|
14 Oct 2016, 11:25 PM | #290 | ||
Junior Member
Join Date: Jan 2010
Location: US, New Jersey
Posts: 22
|
Quote:
This part: Quote:
|
||
14 Oct 2016, 11:39 PM | #291 |
The "e" in e-mail
Join Date: Dec 2004
Location: a virtually impossible but finitely improbable position
Posts: 2,320
|
|
14 Oct 2016, 11:53 PM | #292 | ||
Junior Member
Join Date: Jan 2010
Location: US, New Jersey
Posts: 22
|
Quote:
Quote:
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. |
||
14 Oct 2016, 11:57 PM | #293 | |
The "e" in e-mail
Join Date: Dec 2004
Location: a virtually impossible but finitely improbable position
Posts: 2,320
|
Quote:
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. |
|
15 Oct 2016, 12:10 AM | #294 |
Junior Member
Join Date: Jan 2010
Location: US, New Jersey
Posts: 22
|
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. |
15 Oct 2016, 12:29 AM | #295 | |
The "e" in e-mail
Join Date: Dec 2004
Location: a virtually impossible but finitely improbable position
Posts: 2,320
|
Quote:
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. |
|
15 Oct 2016, 11:20 AM | #296 | ||||
Junior Member
Join Date: Jan 2010
Location: US, New Jersey
Posts: 22
|
Quote:
Quote:
Quote:
Quote:
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... |
||||
15 Oct 2016, 11:57 AM | #297 | |
The "e" in e-mail
Join Date: Jul 2004
Location: Melbourne, Australia
Posts: 2,696
Representative of:
Fastmail.fm |
Quote:
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. |
|
15 Oct 2016, 02:23 PM | #298 | ||||||
Junior Member
Join Date: Jan 2010
Location: US, New Jersey
Posts: 22
|
Quote:
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... Quote:
Yes, it is possible to do MIM for SMTP and disable encryption completely. But it does not mean that industry recommendations should be ignored. Quote:
Probably because: Quote:
Quote:
And that does not go well with that marketing blurb posted earlier, because we can see that the following is no longer valid: Quote:
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. |
||||||
15 Oct 2016, 05:06 PM | #299 |
The "e" in e-mail
Join Date: May 2003
Location: mostly in Thailand
Posts: 3,095
|
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
|
15 Oct 2016, 08:54 PM | #300 |
The "e" in e-mail
Join Date: Jul 2004
Location: Melbourne, Australia
Posts: 2,696
Representative of:
Fastmail.fm |
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. |