OK, you beat me too it Ego, but this is something I was hoping to add to the Email wiki, but first you smarter guys in the room can hammer any technical mistakes or falsehoods first. 
How about this →
Email Provider Criteria
Email is a notoriously insecure protocol which is generally recommended against for critical communications, particularly if exposed meta-data is part of your threat model. [footnote: Notwithstanding the emergence of free (beta), opensource end-to-end encrypted email providers that also encrypt meta-data, such as Scryptmail.]
Defaulting to only using SSL encryption with a centralized email provider is a recipe for a security disaster. SSL-stripping, man-in-the-middle (MITM) attacks and a host of other vectors mean it is only a matter of time before your account is breached and exposed under one of the dragnet surveillance programs in operation world-wide.
Privacy is also impossible if you resort to corporate services like Gmail and Yahoo, which have automated software that scan all incoming and outgoing emails for keywords for advertising purposes. Similarly, Microsoft has a history of reading ‘private’ emails and messages and cooperating fully with LE authorities. Recent security breaches experienced by the large providers - like the billion plus users at Yahoo - are likely state-based actors, and further successful attacks can be expected in the future.
PGP encryption is the best method currently available to protect the contents and attachments of your communications. However, it must be remembered that it does not disguise critical meta-data like: End-to-end email encryption – A case study on ProtonMail design limits and security flaws – arno0x0x
- Who you’ve been corresponding with (recipient email address);
- Email subject line;
- When the message was sent;
- Message size;
- The frequency of exchanges; and
- Unless you use Tor, from which IP address the email originated.
With these factors in mind, there are a number of desirable criteria to consider when selecting a suitable email provider for a new account. This includes, but is not limited to:
- Free services;
- Hosting jurisdictions outside the 5-eyes countries and their allies;
- Deployment of fully open-sourced software that has preferably been audited for security;
- Providers are not in the ‘alpha’ or ‘beta’ stages of development;
- Providers have a history of resisting government interference in the forms of NSLs, gag orders, seizure of data, and other attacks;
- Providers have already withstood serious attacks upon their infrastructure (such as DDOS attacks);
- Providers regularly update their warrant canary on a strict release schedule;
- Compatibility with open-source desktop email providers such as Icedove/Thunderbird;
- Availability of client-side (browser-based) end-to-end encryption to recipients of the same service;
- Compatible client-side (browser-based) PGP encryption for end-to-end encryption to recipients of other email services;
- Email inboxes are encrypted by default;
- Full PGP compatibility and key management, including the importing and exporting of keys and electronic signatures;
- Providers do not keep logs of IP addresses;
- Providers allow anonymous registration of new accounts via Tor;
- Availability of Tor hidden services for logins;
- Availability of two-factor authentification in the form of other devices or tokens;
- Availability of disposable email addresses;
- Availability on a range of devices and peripherals; and
- Ability to obscure or encrypt meta-data.
Email Security Heirarchy
The choice of email provider and set-up is not an easy one. It is determined by many factors, such as the user’s threat model, skill level, financial resources, motivation and willingness to invest time and effort in order to resolve problems.
In general, the most secure, but technically difficult set-up would involve the user establishing their own mailserver based on opensource software and strictly using PGP encryption for almost all emails sent. Unfortunately, this is simply beyond most users and unnecessary for their threat model. Also, this poses many security challenges in the event that something has been misconfigured and the vast majority of internet users do not have PGP key-pairs to begin with, negating the utility of this method.
The next most secure method is for the user to utilize self-created PGP keys, which they alone securely manage, in combination with a secure centralized provider (like Rise-Up), and a desktop email client such as Icedove with the Enigmail plugin. The user also has the ability to utilize split-GPG architecture in Qubes to protect from the theft of their private key. Split GPG | Qubes OS Again, the limitation of this approach is that PGP key-pairs are hardly ubiquitous, meaning most emails will be sent to recipients using standard SSL encryption.
The most usable method for PGP end-to-end encrypted emails, which involves an important security trade-off, is to use a centralized email provider such as ProtonMail or Tutanota. In this case, a desktop email client and PGP key management are both unnecessary, as all encryption is performed client-side (in the browser) with Javascript libraries.
The benefit is that the user does not have to manage PGP keys, only one password is required to send encrypted emails, and emails to users of the same service are automatically encrypted end-to-end. On the downside, the benefits are counter-balanced by the huge attack surface of the browser, reliance (often) upon the broken Certificate Authority (CA) system for server authentication, risk of modification of the application code server-side (leaking the mailbox password), the theft of the encrypted private key stored on the mailserver, and other factors.
The Case for ProtonMail
ProtonMail Threat Model
Protonmail is aimed at users who want to guard against mass surveillance. It is not intended for users who are at high-risk, such as the next potential Edward Snowden. It does not protect against: The Proton Mail Threat Model | Proton https://www.wired.com/2015/10/mr-robot-uses-protonmail-still-isnt-fully-secure/
- Users with already compromised machines e.g. infected with malware, keyloggers etc;
- Man-in-the-middle attacks, where an adversary sits between the user and the ProtonMail servers and sends the user’s browser a modified version of the ProtonMail website;
- Unauthorized backdoors, where ProtonMail servers in Switzerland are accessed and the software is changed to send bad encryption code to the user’s browser, or compromised public keys are sent to execute a MITM attack; and
- Knowledge of whether a message sent to another user is being encrypted with the correct public key stored on ProtonMail’s keyserver (potential eavesdropping risk).
Fortunately, Protonmail has just established a new Tor hidden service for ProtonMail, which also includes an Extended Validation (EV) certificate, increasing the difficulty of targeted MITM attacks. The service can now be accessed at:
https://protonirockerxow.onion
The benefit of using the hidden Tor service includes: Fighting Censorship with Proton Mail Encrypted Email Over Tor | Proton
- Adversaries will find it difficult to know you are accessing the service;
- Tor’s extra layer of encryption makes MITM attacks more difficult;
- Attempts to censor the use of Protonmail by governments will be more difficult;
- The service is more resistant to DDOS attacks;
- The weakness of just relying on the CA system for end-to-end authentication is mitigated;
- It is more difficult to serve malicious code to a targeted individual based on their IP address; and
- The EV status of the certificate reduces the threat of phishing attacks by impersonators.
Protonmail Features
Protonmail meets a number of the suggested criteria for selecting a suitable email provider. For instance: How Safe is Proton Mail? Security Features Explained
- ProtonMail has withstood recent attacks on its infrastructure;
- A free service is available;
- It is outside the 5-eyes jurisdictions;
- It is available on a range of devices or peripherals;
- Strict warrant canary updating is in place;
- Messages are stored in encrypted format on ProtonMail servers at all times;
- Messages are encrypted in transit between servers and user devices;
- Data is encrypted and inaccessible to ProtonMail staff due to client-side encryption;
- Opensource deployment software and cryptography is used e.g. AES, RSA and OpenPGP;
- Data never goes to the cloud;
- No tracking or logging of personally identifiable information;
- No targeted advertisements are served;
- Emails sent can be set to be automatically deleted after a set time period (those sent to both non-ProtonMail addresses and ProtonMail addresses);
- Encrypted emails can be sent to non-ProtonMail addresses;
- Two-factor authentication is available;
- Full PGP key management is available;
- Tor Browser registration is possible; and
- A Tor hidden service is available.
Additionally, features already incorporated or on their roadmap for development include: 2016 Email Security Roadmap | Proton
Authentication:
- Challenge/Response login password improvement so that every login uses a different one-time hash.
- Store mailbox password in memory only, not session storage. This means the user will have to re-enter the mailbox password if the page is refreshed, but will avoid the mailbox password ever touching the disk if the browser caches session storage.
- Two factor authentication.
Server
- Public Key Pinning (HPKP): This pins our certificate such that we can’t be impersonated if a root CA or intermediate CA is compromised.
- Content Security Policy (CSP): An extra layer of XSS protection which disables all inline scripting and whitelists only our domain for loading Javascript.
- Migration to Certificate Transparency (CT) for EV Certificates.
- DNS-based Authentication of Named Entities (DANE).
Full PGP Support
- Support importing PGP public keys of contacts so PGP emails can be sent automatically through ProtonMail.
- Support keychain functionality so users can import their own public/private keys.
- Allow the export of ProtonMail user private keys.
Application Security
- Add ProtonMail SSL certificates to the HSTS browser preload list(s). This needs to wait until we have stabilized our certificates.
- Client-side public key verification mechanism for recipients. This allows you to automatically check the fingerprints of recipient public keys to ensure that there is no key spoofing.
- Browser extensions or desktop applications so client side code does not need to be loaded each time ProtonMail is accessed.
- Splitting the ProtonMail webmail into a separate subdomain isolated from other services.
- Adding a Web Application Firewall (WAF).
Conclusion
While Protonmail is not a perfectly secure solution or privacy magic pill, the perfect should not be the enemy of the good. Many criticisms aimed at the service have been addressed in recent times, with others on their roadmap. End-to-end email encryption – A case study on ProtonMail design limits and security flaws – arno0x0x Mr. Robot Uses ProtonMail, But It Still Isn't Fully Secure | WIRED
ProtonMail is likely a suitable solution for the threat model of most Whonix users, who desire a usable solution that provides resistance against mass surveillance programs targeting emails. This of course requires them convincing their friends and family to also make the switch. In addition, secure use of the service can probably be increased when used in combination with a Disposable VM in the Qubes-Whonix architecture and a suitably long and unique Diceware passphrase.
