Shortly after publishing this original post, many of my concerns were addressed. ProtonMail now supports sending mail that is signed and/or encrypted using OpenPGP. This is a huge benefit to the secure-email community. It is also possible to use your own key which allows me to use a trusted key that is already known to the community. There were other features added which are important to securing the overall infrastructure. ProtonMail seems to continue to make strides to make a more secure world for those of us that care about our privacy.
There are several "private" email providers that advertise encrypted email storage as well as other security services to help protect your privacy and data online. ProtonMail may be one of the unique providers that actually hides their servers inside a mountain in Switzerland affording them both physical and political (legal) protections beyond what other providers can offer. While some of the features offered by ProtonMail are truly unique in the arena of even private-email providers and should be lauded by the information security community, several implementations of these features, and some policies, are down right confusing and break traditional functionality that many are used to.
As a user of the service over the past few months, there have been times when I’ve both wanted to shake the hands of the developers as well as shout in frustration at how a feature was implemented. Today, I’ll try to document some of the pros and cons that I would have wanted to know before moving my email over to the service.
The ProtonMail website and blog both discuss the storage of email on their servers as being encrypted with OpenPGP. This prevents ProtonMail admins, attackers, and anyone else trying to gain access to the email stored on the server, from gaining access to the contents of your messages. It should be stressed that like using OpenPGP elsewhere, only the contents of your message is encrypted and the metadata is stored as clear text.
One feature that may not be immediately apparent is that because an OpenPGP key pair has to be created for each account in order to store messages encrypted, this key pair can also be used by external users to send encrypted messages to you. This provides a real end-to-end encryption (E2EE) solution for users. The private key, necessary for decrypting the messages, is stored encrypted on the server and is decrypted with your ProtonMail password. Also, any message sent to or received from a ProtonMail user is automatically encrypted.
One problem that has been found in this process is if you try to use your own OpenPGP keys on top of, or in lieu of, the ProtonMail encryption, bad things happen. One might take a standard PGP-encrypted message, and try to insert it as plain-text in the email content field. ProtonMail will take this message and munge it to the point that what actually gets sent may or may not be decipherable. Similar things happen when someone sends a message to a ProtonMail user using a different key than what ProtonMail is expecting. This is unfortunate as someone wanting to provide an additional layer of security, by using a key pair that they physically control, is unable to do so.
Another problem in this system is the lack of sending messages encrypted with OpenPGP. If a ProtonMail user is sending a message to an external-to-ProtonMail user, they cannot encrypt the message with OpenPGP. This can be a confusing bug as the opposite is possible.
The solution, by the way, provided by ProtonMail is to provide a password (OpenPGP being used to do symmetric encryption?) that can then be passed to the external user by a separate means, for them to be able to open the message using a special URL. The problem, of course, is getting the password to the external-user in a secure method.
Lastly, at this time it is impossible to rekey your account so if, some how, the OpenPGP keys needed to be superseded it could not be done.
Webmail and IMAP/SMTP
ProtonMail’s webmail is nice and feature-rich but not overly confusing to use. There is also a security benefit to having one’s messages physically stored on the server with no real way to export them. Because everything was always on the server, there would never be a local copy that could be stolen (encrypted or not). Of course this also limited the ability of people to be able to move away from ProtonMail, if they chose to do in the future, as their data would be forever locked away and they couldn’t bring it with them.
I frown on vendor lock-in on every level and this was a big lock-in. The developers kept talking about the forthcoming ProtonMail Bridge which was to provide local decryption of messages and a local IMAP and SMTP server that would allow local clients to connect to the ProtonMail email servers and download their messages (along with sending and receiving messages outside of the webmail GUI). When the official release came I was extremely disappointed to see that while Windows and macOS were both supported, the Linux version was still marked as "Coming Soon" (and still is as of this writing). It was only much later that I happened to find an utterance of a beta program for the Linux Bridge that I could join to get early access. As I’m not shy about beta testing software, I submitted my request and was rewarded with a download URL link. Since then I’ve been using the webmail instance, Thunderbird, and the mobile app and haven’t found any issues with the Bridge causing problems. This does solve my vendor lock-in fear as I can pull my messages out and move to a different provider at any time.
Here’s the one big issue that is not technical in nature and is causing me some major headaches: limits to the number of addressees on an outgoing message.
ProtonMail doesn’t explicitly tell you what the limit is for the number of people you can send a message to but may mention that there is a limit. That number, by the way, is 25. Sure, how often do I send a message to twenty-five individual addresses? Not often! But when I do, I really need to… R I G H T N O W!
Here’s my use-case: I am on a search and rescue team that uses email for disseminating information quickly to a large number of email addresses. The last mission I was on I found myself as first on scene and needed to convey where the incident command post was setting up. If only I could do something simple like replying-to-all on the message I had just received to let everyone know to meet me at the intersection I’m standing in. Nope, could not do it.
ProtonMail support will tell you that this "feature" is in place to protect the reputation of ProtonMail and not allow it to become a haven for spammers. While I can sympathize with their problem, I feel this is not the way to go about fixing the problem. In my case, it has limited the ability of a paying customer to legitimately do work. And this is a unique "feature" among email service providers.
ProtonMail also supports Tor users with an .onion address to access their services. This means that you can connect to ProtonMail over Tor end-to-end which helps reduce the attack surface of the communications going across the Internet. Overall, this is a positive step for helping people preserve their privacy through anonymity but there is one piece that seems to have been left out: .onion email addresses.
There are some email providers that provide .onion addresses for people to use exclusively on the Tor network. None of the providers have been anyone that I would trust my messages with, long-term, only because I fear they may disappear tomorrow. ProtonMail is different in that regard and it would be very interesting to see them take on this as a challenge.
Overall, I like what ProtonMail is trying to do. For the average person it probably works very well. But as soon as you try to push the system to where you expect it to be, disappointment appears on the horizon.
I was a paying member before I started using the service full-time because I believed in what they were trying to do. I am used to dealing with software bugs and testing software to find flaws so many of the downfalls I’ve spoken about are things that I’m sure will be remedied soon. The sticking point, to me, is the self-imposed limit to addressees in outgoing mail for paying customers. I’m not exactly sure how I want to deal with this bug but it may curtail my funding the project in the end.