Mailfence is not vulnerable to GNU/Linux TCP Vulnerability

shield-ok-icon

Recently a GNU/Linux TCP vulnerability was disclosed (CVE-2016-5696) by security researchers in the US. Upon analysis, this bug did not pose a threat to our users. Nevertheless, we have already taken supplementary measures in the last week to further harden Mailfence’s servers.

GNU/Linux TCP Vulnerability

The vulnerability which was discovered has been present in the GNU/Linux kernel since 2012. It requires an attacker to have the IP addresses of both the client and the server. Due to a rate limit enforced by GNU/Linux kernel on TCP challenge ACK packets, it is possible to hijack the TCP connection between the client and the server. This can (for example) allow an attacker to inject malicious code/data into the communication HTTP (web) stream.

This vulnerability can be exploited without needing to have man-in-the-middle (MiTM) capabilities. Thus, the attack can also be performed “off-path” without the ability to eavesdrop on the network between client and server.  This significantly reduces the difficulty of the attack. Additional details can be found in this original research paper.

Protecting our users

While this vulnerability can sound severe, its impact is limited in practice for users connected to our servers. At worst, arbitrary TCP connections could theoretically be closed and no hijacking could take place, because of the use of TLS encryption. For Web sessions in particular, our HSTS policy ensures that HTTPS (instead of HTTP) will be used right from the start.
Moreover, to further protect our users from this DoS-like possibility, our security team has already taken the necessary measures, without waiting for the new kernel packages to be released.

Follow us on twitter/reddit and keep yourself posted at all times.

– Mailfence Team

Mailfence high-level security analysis

image1[1]

All crypto operations relating to private key, and the bodies of emails are performed after user unlocks the key with the respective passphrase.

Following table will provide a high-level security analysis overview with respect to the type of information and the level of protection that it holds.

Type of Information

Level of Protection

Source of random data when creating new PGP keys Entropy collected via the client device
Password encrypted in transmission from browser to web server SSL/TLS
Password securely stored on web server SHA256 (iterated and hashed)
Passphrase exposure Passphrase check for all crypto-activty always occurs on the client side – and never gets exposed to the server.
Private key encrypted in transmission between browser and web server Two-layers of encryption:
1- With user passphrase (via AES)
2- TLS/SSL
Private key encrypted in storage With user passphrase (via AES)
Private key decrypted on web server Does not apply to Mailfence – as all the private key en(de)cryption occurs on the client side with the user passphrase.
End-to-end encrypted messages during transmission from client browser to Mailfence servers Two layers of encryption:
1 – SSL/TLS
2 – PGP
End-to-end encrypted messages body and attachments during transmission between web server and recipient email account PGP (plus TLS if supported by recipient)
End-to-end encrypted messages body & attachments encrypted in storage on web server PGP
End-to-end encrypted messages body & attachments known to web server Never – as all the crypto-operations concerning end-to-end occurs purely on the client side.
Message headers encrypted during transmission from browser to web server SSL/TLS
Message headers encrypted during transmission between web server and recipient email account TLS (if supported by recipient)
Message headers in storage on web server Not encrypted

Vulnerability Analysis

The following points apply to emails sent using end-to-end encryption:

Attack Level of Protection
Attacker is listening to your Internet connection Protected
Attacker gets access to email stored on the server Protected
Attacker gets access to the server’s databases Protected
Attacker compromises webserver after you have accessed your email Protected
High-level MiTM attack – where an adversary sends you a false code for all the crypto-related operations to check Not protected
Attacker has access to your account Protected (but the sent end-to-end encrypted messages will be viewable in clear text)
*this is planned to be mitigated
Attacker has access to your computer before you access your email (and can install programs such as key logger/malware…) Not protected

Don’t hesitate to contact us in case you have more questions about High-level security analysis of our service.

Also, follow us on twitter/reddit and keep yourself posted at all times.

– Mailfence Team

Mailfence end-to-end encryption and digital signatures

End-to-End Encryption (E2EE)
Is a method used for securing encrypted data while it’s moving from a source to a destination. With End-to-End Encryption, data is encrypted on the sender’s system and only the intended recipient will be able to decrypt it. Nobody in between (be they an internet/application service provider, surveillance programs or a hacker, …) can read or tamper with it – thus providing a great deal of confidentiality and protection to all communications.

Digital Signature
Is an equivalent of a handwritten signature or stamped seal, but offering far more inherent security. A digital signature is intended to solve the problem of tampering and impersonation in digital communications – and provides absolute authenticity and integrity to all messages.

How do we do it

Mailfence uses OpenPGP, a time-honored protocol designed by Phillip Zimmermann, which got further refined in RFC-4880 along with S/MIME protocol.

We leverage the OpenPGP.js – a Javascript implementation of OpenPGP standard which is open-source and well-audited. It allows us to perform all the complex crypto-operations of en(de)cryption purely on the client side, without exhausting the device’s resources.

Glance of operations in step-wise manner
Every crypto process encapsulates a series of different steps working back and forth between the client and the server over TLS/SSL – in order to successfully carry out a particular operation. Below you will find a step-by-step linear diagram that illustrates how Mailfence End-to-end encryption and digital signatures functions along with other relevant details.

Mailfence to Mailfence

Mailfence to Mailfence

Mailfence to other email providers
  • Mailfence to Outside worldKey generation
    1. The client-browser requests the specific key-generation code from the server after receiving a request from the user – and the server sends that specific code to the client’s browser.
    2. The key then gets generated on the user device (in browser) and gets encrypted with the provided passphrase via AES-256. The public key at this point also gets published on public key servers (if the user has opted for that option as well).
    3. The encrypted key is then pushed onto the server from user’s browser – so that a user can access it any time from any device in a secure and protected manner.

* For private key import (encrypted already with the user passphrase) – steps 1-3 will be skipped.

  • Passphrase changing
    1. The client-browser requests the specific passphrase changing code along with the related encrypted key from the server after receiving a request from the user – and the server sends that specific code with the related encrypted key to the client’s browser.
    2. User decrypts the key by providing the respective passphrase and encrypts it with the new one.
    3. The encrypted key is then pushed back to the server from the user’s browser.
  • Key revocation
  1. The client-browser requests the specific key revocation code along with the related encrypted key from the server after receiving a request from the user. The server sends that specific code with the related encrypted key to the client’s browser.
  2. User decrypts the key by providing the respective passphrase.
  3. The key then gets revoked and its revocation status also gets published on public key servers (if user has opted for this option). The key then gets encrypted back with user passphrase.
  4. Client browser then pushes the encrypted key back to the server.

* For generating revocation certificate – In step 4, instead of revoking the key, the application will generate a revocation certificate – which user can use at any later stage to claim the key revocation.

  • Key Export
    1. The client-browser requests the specific key exporting code with the related key from the server after receiving a request from the user and the server sends that specific code with the related encrypted key to the client’s browser.
    2. The user then exports (downloads) that encrypted key onto his device.
  • Key Deletion
    1. The client-browser requests the specific key deletion code with the related key from the server after receiving a request from the user and the server sends that specific code with the related encrypted key to the client’s browser.
    2. The user then deletes the encrypted key onto his device.
  • Key expiration date modification
    1. The client-browser requests the specific expiration date modification code with the related key from the server after receiving a request from the user – and the server sends that specific code with the related encrypted key to the client’s browser.
    2. User decrypts the key by providing the respective passphrase and modifies the expiration date. The key then gets encrypted back with user passphrase.
    3. Client browser then pushes the encrypted key back to the server.
  • Sending a digitally signed email
    1. The client-browser requests the specific digital signing code with the related key from the server after receiving a request from the user – and the server sends that specific code with the related encrypted key to the client’s browser.
    2. User decrypts the key by providing the respective passphrase.
    3. The composed email message gets digitally signed (PGP/MIME) and then sent to the recipient.
    4. The key then gets encrypted back with user passphrase and pushed back to the server.
  • Sending an encrypted and digitally signed email
    1. The client-browser requests the specific encryption and digital signing code with the related key from the server after receiving a request from the user – and the server sends that specific code with the related encrypted key to the client’s browser.
    2. User decrypts the key by providing the respective passphrase.
    3. The composed email message gets digitally signed (PGP/MIME), encrypted with the public key of the recipient (OpenPGP) and then gets sent.
    4. The key then gets encrypted back with user passphrase and pushed back to the server.

For a detailed “How to” user manual, please check this link as well.

Also, follow us on twitter/reddit and keep yourself posted at all times.

– Mailfence Team

Thoughts on online privacy

image06

Patrich de Schutter is a typical serial entrepreneur. He founded Allmansland, one of the first web agencies in Belgium back in 1994; A couple of years later he launched IP Netvertising, the first ad-sales house in Belgiun, which was later sold to RTL; In addition, he also took part in a number of successful ventures, including rendez-vous.be, Belgium’s first ever dating site, and express.be the only independent business news site in Belgium.

In recent years, he’s been operating ContactOffice, a virtual office software, and mailfence, an email privacy service, while devoting himself to fighting internet privacy violation and for improving the safety of users in Belgium and world-wide.

In this interview, he tells us his thoughts on online privacy, international law, personal privacy and everything in between…

To get more updates follow us on twitter (@mailfence) or subscribe us on Reddit: /r/Mailfence

Get your free account and reclaim your email privacy !

Mailfence Release Notes v4.4.017

image1

After accepting Bitcoins and increasing the Mail storage, we’re now happy to announce our next Mailfence Release Notes v4.4.017.

New Features:

  • Users can now authenticate (Web, SMTP relay, IMAP, POP, ActiveSync) using email address instead of their login name.

Improvements:

  • Some PGP signed messages were wrongly signaled as incorrectly signed. This is now fixed.
  • The parsing of vCalendar/iCal format has been improved.
  • We increased the number of colours in the Calendar

We are currently on the pursuit of a massive improvement cycle – and will duly keep you posted.

Feel free to report any found bugs/queries/suggestions to support_at_mailfence_dot_com

Also, follow us on twitter/reddit and keep yourself posted at all times.

– Mailfence Team

Mailfence threat model

We believe that every user has the right to know exactly what threats Mailfence is designed to PROTECT or NOT PROTECT you from.  That’s why we’ve composed this generic Mailfence threat model.

‘Mailfence’ will PROTECT YOU against:

  • Eavesdropping on your internet connection – When you are using Mailfence, the connection between your computer and the Mailfence server is protected by (SSL/TLS) encryption. That means if someone is eavesdropping on your Internet connection, they will not be able to read the traffic that you send to our website. This is especially important if you are using your computer from a public or office network, or if you are using a wireless connection that is not encrypted.
  • Mass surveillance – Perfect for an individual (or corporation) that does NOT want the government (or other non-state actors) to have access to all of their emails at any time. Mailfence does not operate like the gigantic American players (Google, Microsoft, Yahoo…) who continuously scan and archive all of your conversations. Our end-to-end encryption technology (E2EE) is designed to guard you against anyone who is trying to snoop your email privacy by giving absolute confidentiality and integrity to all of your messages – where only a designated recipient can read the content of a message via decrypting it through his/her private key.
  • Message Forgery / Tempering Attacks – With digital signatures, ‘Mailfence’ gives you the possibility of having absolute authenticity and non-repudiation – thereby making it the only solution which provides the complete CIA triad to its users and makes it an ideal platform for not only privacy enthusiasts but also for professionals (doctors, engineers, lawyers, journalist, teachers, students…) to exercise their online liberty to the fullest.
  • Compromised Account - If your account password gets compromised – the protective layer of passphrase over your private key will restrict an attacker to perform any crypto-activity (send any encrypted and/or digitally signed messages, performing operations on your key store…) and to read any of the encrypted emails that have been sent to you by other people. Thereby preserving the confidentiality and integrity of your encrypted content to the max.
  • Data Theft  – Let’s say if a strong adversary (state or even a non-state actor) somehow breaches our servers to get hold of our data (which is highly unlikely to happen) – all of your encrypted content will remain intact and no adversary will be able to decrypt it, as it will require your private key that has been protected by your passphrase (which you and only you knows). Also, to reduce the odds of cracking-down a private-key by using heavy-state machinery & resources, the default length of every generated Key-Pair has been set to 4096 bits (being generated with strong entropy) – some folks will say it only provide a bit of extra security comparing to 2048 bits – well, we say that we don’t mind grabbing that extra).

‘Mailfence’ will NOT PROTECT YOU against:

  • A compromised device – If your device has been compromised by a malware, keylogger etc (which is not very difficult to perform these days, especially if your adversary is a state actor) then E2EE and other security measures are useless. In fact your adversary can use your account to further spoof your identity and damage your online presence on a large scale. (keep an eye on ‘tips’ in our blog to follow better practices)
  • Compromised or forgotten passphrase – This is yet another and unfortunately a common case. If your passphrase has been compromised (let’s say via a malware, keylogger or through the use of bad practices – writing it somewhere, sending it in clear text, ……) or you simply have forgotten it – then you’ll be in serious trouble and we will not be able to help you in anyway, except to urge you to change your passphrase or simply revoke that keypair and use a new one. (see ‘How to‘ for more details)
  • A high level Man-in-the-Middle (MITM) attack – High level Man-in-the-Middle attack is a kind of attack where an adversary (typically a state actor) can create a clone of Mailfence in an extremely sophisticated manner (forging our certificate – which is very hard but not impossible, authenticating user’s on false grounds, etc.) and somehow also faking all the services that Mailfence provides in order to fool you into confusing us with them for compromising your data at large. Provided the complexity and difficulty of such an attack – it is often considered as a threat only from high-level adversaries (state actors…). Due to our efforts into getting a CA certificate (having no american company in the chain etc) and providing you with the possibility of verifying our SSL/TLS certificate, we have guarded our defenses to a maximum possible extent.
  • Heavy state-funded attacks (DDoS, breaking the crypto, planting a backdoor etc.) DDoS (a distributed Denial of Service attack) is usually aimed at shutting-down an entire service (website) thereby forcing their users to not use it anymore. In our more than 15 years of operating a cloud messaging service, we have already  been into certain situations of this kind and have done our best to mitigate such a threat. Other common state funded and resourced attacks like (Breaking the crypto, planting a backdoor, sending you a bad Javascript code, …etc) can also potentially happen – as the saying goes ‘Nothing is impossible’. However, we on our side have taken every (humanly) possible measure to mitigate such kind of threats.

Before any final thoughts – we would like to state clearly that Mailfence should not be used for any illegal activity and that we comply with the Belgian Law (see our Privacy Policy for more details). Consequently, our service is ideal for protecting sensitive business communications, private & personal data – for both professional and personal users of all sort (doctors, engineers, lawyers, journalists, teachers, students…).

Now, Mailfence is a state-of-the-art solution which provides (pretty) good privacy and security.  We do realize there are users who may have specific adversaries that are focusing enormous resources towards their targets – and that’s where even crypto might not do much as this comic will possibly illustrate.

‘Privacy is a right, not a feature’ – is the belief that lies at the very foundation of Mailfence and we’ve done all we can to stand by this statement.

Follow us on twitter/reddit and keep yourself posted at all times.

– Mailfence Team

Is SMTP STS a major step towards email security?

download

The underlying 1980s transport protocol used to send emails: Simple Mail Transfer Protocol (SMTP) is ancient and lacks the ability to properly secure email communication. To level-up its security, SMTP STARTTLS was invented in 2002 – but it still turned out to be susceptible to Man-in-the-middle (MITM) and connection downgrades attacks.
It order to raise the security bar a new protocol, SMTP Strict Transport Security (STS) has been drafted (after 14 years of staggering wait since the last attempt). This time all the major players (Google, Microsoft, Yahoo, Comcast, LinkedIn, and 1&1 Mail…) have joined forces to make this effort a success.

What is the goal of this new standard ?
SMTP STS has been designed in order to prevent Man-in-the-Middle attacks.

How does SMTP STS improve SMTP Security versus StartTLS?
SMTP STS will work alongside with STARTTLS to strengthen SMTP (on the whole) and to avoid connection downgrade and Man-in-the-Middle attacks. It will check if the recipient supports SMTP STS and has valid & up-to-date public key certificate, if yes it will pass email securely to the recipient. If no, it will stop the email from sending and will notify the user with the reason.

How long will it take to come into effect ?
Currently, it is only a draft proposal, and it will take a while before major players start implementing it and the Internet Engineering Task Force (IETF) has six months in total to consider the possibilities of this new proposal (the motion will expire on September 19, 2016).

Will it be enough to restore email privacy ?
Is SMTP STS a major step towards email security and enough to restore email privacy?  Our answer is NO.
It’s here where things start getting a bit fishy – as strengthening SMTP security will only protect emails from source SMTP to destination SMTP servers – and that’s it.

Consequently, follwoimain concerns will remain:

– The messages will stay in clear text, from sender’s device till it reaches the respective sender SMTP server .
– The SMTP server (both on the sender and recipient side) will be able to view the message in clear text.
– The message will remain in clear text, from the recipient’s SMTP server till reaching the recipient’s device.

These massive gaps are where adversaries will be able to successfully exploit the confidentiality and integrity of emails.

So what is the best way for restoring email privacy ?
End-to-end encryption (E2EE) is the only answer – where a sender encrypts an email (with the public key of the recipient) and the recipient decrypts that email with his/her private key – with all these operations occurring purely on the client-side. This approach leaves no room for an adversary to actually sniff the clear text messages. Mailfence is by far the only secure emailing service – that provides a “true” E2EE secure emailing service alongside the capability of Digital signatures.

Simply put, SMTP STS should not be compared with the E2EE’s provided level of security. However, it still is a step in the right direction while remaining a small part of the puzzle !

Follow us on twitter/reddit and keep yourself posted at all times.

– Mailfence Team

Mailfence accepts bitcoins

Bitcoins are taking over the crypto-currency marketplace and are one of the best ways to preserve one’s privacy. They’re now the largest and most well-known digital currency. As one of the leading secure email providers, we are happy to launch our support for bitcoin payments (in beta).
Mailfence accepts bitcoins
Users can use bitcoins for payment of both premium plans (Entry or Pro) and/or for donations in order to support us in developing the most secure and private email solution.  In line with Mailfence philosophy of giving full control to the user, we also offer to pay with credit card or Paypal.

 

Discover our premium plans:

Start with the free plan. If you love it, take one of the premium plans. The Entry plan is at 2,5 EUR per month, the Pro plan at 7,5 EUR per month

plans
 How to pay with Bitcoin:

Interested in discovering one of our premium plans? Log into your account. Click on your name at the top right of the screen and click on ‘Subscriptions’. You’ll discover the different plans. Select the subscription of your choice and click on the Bitcoin icon at the bottom right. Click on Next and you’ll discover the following screen with bitcoin payment instructions.

bitcoin upgrade

 

Follow us on twitter/reddit and keep yourself posted at all times.

– Mailfence Team

The Mailfence SSL/TLS Certificate

 

SSL-TLS Certificate

When accessing mailfence.com, the transmission of information between your browsers and our servers in Brussels-Belgium is always encrypted and protected by SSL/TLS – for which each website has a Public Key Certificate that is verified by a trusted certificate authority.

Mailfence has no American company in its SSL/TLS certification chain and the one which vouches for us is Keynetics (presently called https://www.opentrust.com/).

A modern browser should automatically check the validity of the Mailfence SSL/TLS certificate and alert you if it detects something untrustworthy.  For security conscious users who want to manually check, our SSL/TLS certificate fingerprints/thumbprints (valid until 13/05/‎2018) are:

SHA1 fingerprint:

dd:25:6f:c4:b6:29:e6:8f:a9:d2:19:f6:c2:4b:9c:15:ea:79:5e:90

SHA-256 fingerprint:

e7:68:06:a0:be:08:d6:92:59:af:21:86:39:df:23:17:60:45:54:4a:d8:a2:a7:e0:57:5c:45:aa:1d:57:21:85

If this matches what you see in your browser, then you know you are communicating with the real Mailfence website and using the correct public key to encrypt your sensitive information and only Mailfence can decrypt it.

 

Guidelines:

  • For Chrome:
    1. Click on the lock button in front of the URL.
    2. Go to Details and click on View Certificate.
    3.  In Details tab, show All and verify the Thumbprint (SHA1) matches the one above.
  • For Firefox:
    1. Click on the lock button in front of the URL and click on More Information.
    2. Go to Security and click on View Certificate.
    3. In General, verify the Fingerprints (SHA1 & SHA-256) matches the one’s above.
  • For Safari:
    1. Click on the lock button in front of the URL.
    2. Select Show Certificate, in Details scroll to the bottom of the page and verify the Fingerprints (SHA1) matches the one above.

Note:  Make sure you are looking at the certificate for *.mailfence.com

For further assistance, feel free to drop us an email at support@mailfence.com

Follow us on twitter/reddit and keep yourself posted at all times.

– Mailfence Team