With the new version 3.0, which can look back on a relatively long development period (from January to August 2018), Mailvelope is extended by two completely new possible applications. In addition to e-mails, form data can now also be transmitted end-to-end encrypted in the Web. Apart from that, the connection to GnuPG offers increased security and flexibility.
With the GnuPG integration, we are now able to address also those users who were skeptical about the use of cryptography in browsers: As of version 3.0, a locally installed GnuPG application (e.g. Ggp4win or GPGTools) can also be integrated into Mailvelope.
The user now has the choice whether they want to have the key management and encryption routines done by OpenPGP.js or by the locally installed GnuPG application. A welcome side effect of this new flexibility of Mailvelope is that security has been increased by a further step. On the one hand, security tokens such as a smart card can now also be used in conjunction with Mailvelope, and on the other hand, the private keys in GnuPG are better protected if the browser is compromised.
More about GnuPG integration and the possibilities of using hardware tokens will soon be available in a separate blog article.
Version 3.0 is a further development that opens Mailvelope for future applications beyond email encryption. The use of web forms is widespread and the new General Data Protection Regulation (GDPR) is not the first to make it clear that confidential data is often transmitted in this context.
Mailvelope now offers the possibility to define forms in a certain format so that the data can only be read by a selected recipient. The Mailvelope Browser extension takes over the encryption and packages the form data in a secure OpenPGP message.
A technical documentation on encrypted forms is available in the Mailvelope Wiki, further examples of usage will be published soon.
At the beginning of an encrypted communication with OpenPGP, the public key of the communication partners must first be exchanged. In order to guarantee a process that is as user-friendly as possible, we already chose a central approach in 2016, the Mailvelope Key Server, to simplify and partially automate the exchange of keys.
Starting with version 3.0, we now also support a standardized procedure that follows a decentralized approach: With Web-Key-Directory, the keys can be retrieved directly from the e-mail provider's website, provided the latter supports the procedure.
In Mailvelope 3.0, the encryption library OpenPGP.js has been updated to version 4.2. In addition to numerous improvements, Mailvelope thus receives support for the ECC (Elliptic Curve Cryptography) encryption method. In addition, this update of OpenPGP.js also improves security (release notes OpenPGP.js 4.2).
The new developments in version 3.0 were made possible by a project of the German Federal Office for Information Security (BSI). We’d like to thank all participants for the good cooperation and the associated improvements of Mailvelope.
Security researchers from the University of Münster and Bochum in Germany and of KU Löwen in Belgium have yesterday released their research paper Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels.
A common misconception with the interpretation of Efail has been that the OpenPGP standard as such is broken. What we see instead are implementation errors in email clients when integrating PGP functionality. Mailvelope is not an email client and the architectural separation between webmail client and the Mailvelope browser extension that encapsulates the encryption logic has shown to have advantages in the resilience against the Efail findings. Mailvelope is not affected by those critical vulnerabilities.
In the following we will provide an overview of vulnerabilities found and their possible impact on Mailvelope and its users.
The findings of the Efail paper can be divided in 3 categories.
According to our view this is the most severe finding. This vulnerability can be used to give an attacker access to the complete plaintext of an encrypted message and was found in email clients like Thunderbird or Apple Mail.
The exploit uses implementation errors in emails clients that result in insufficient isolation between decrypted content and other parts of the email structure. Mailvelope is not affected by this vulnerability. There is a strong isolation between the decrypted content of the email and the webmail client that prevents this sort of attack in Mailvelope.
The Efail authors describe an attack on the CFB mode used in OpenPGP to exfiltrate the plaintext. Deficiencies of this block cipher mode that uses unauthenticated encryption are well known and led to the introduction of integrity protection in OpenPGP with the MDC feature (around the year 2000). A PGP client that strictly enforces usage of integrity protection is not vulnerable to Efail's "crypto gadgets".
OpenPGP.js as the underlying crypto library of Mailvelope has a strict check on integrity protection since 2015 that prevents this type of attack for the vast majority of all PGP keys generated in the last ~15 years that have AES as the preferred symmetric encryption algorithm, which is the default in all relevant PGP implementations.
In summary: Mailvelope users that have generated their private key in Mailvelope or in general use PGP keys which are not older than ~15 years are not affected by the CFB gadget attack.
The remaining risk of older PGP keys has been eliminated with the release of Mailvelope 2.2.2 today where we completely block decryption with unauthenticated older algorithms.
Mailvelope does not block external resources loaded in HTML emails. As a result there is a general problem with leaking meta data. This is a known issue in Mailvelope and we are planning to block external resources in HTML emails by default and make loading only optionally available.
But this problem should not be confused with the critical direct exfiltration of plaintext as described above. An attacker could at most find out about the IP address of the Mailvelope user or the time the email was decrypted, but never about the content of the message.
Efail has found severe issues in email clients but also created a lot of uncertainty due to media coverage and the notion of PGP being broken. The impact of the Efail findings on Mailvelope users are minor, there has been no way to extract the plaintext of the message in Mailvelope, if the PGP key has been generated with Mailvelope and the communication was from a Mailvelope to Mailvelope user.
Still we are constantly working on improving Mailvelope, and an upcoming release should provide improvements towards the elimination of leaking meta data.
Besides the many technical modifications that became necessary through the adaption of Mailvelope to Firefox Quantum, designing a simplified and improved menu prompt for Mailvelope was what kept us busy last year.
What is the user experience like in the interaction with Mailvelope? What are the particular obstacles that new users are met with? We were able to go further into this question within the framework of the USABLE Project by Internews and draw on the experiences made by security trainers. Common points of criticism related to Mailvelope’s former main menu and trouble that new users were faced with during the setup process.
This is why the menu prompt in version 2.1 and 2.2 after installation was restructured and key UI elements were redesigned in close collaboration with the team of the password manager passbolt.
A landing page now points to the new icon in the browser immediately upon the installation of the extension.
Above that, the user is offered a Getting Started wizard with the generation of keys upon the first start of Mailvelope.
After configuration, the main menu with the new icons will show the functions that are most commonly required for everyday use.
In addition, Mailvelope offers a new, redesigned dashboard.
Text can now be encrypted and decrypted in Mailvelope‘s main application. In this way, PGP can also be used without regard to a mail provider.
Further improvements of the user interface, such as a Guided Tour, are currently in the testing phase and will be gradually included in future versions.
Version 2.0 has yet again made Mailvelope clearly safer, faster, and more comfortable.
Even before the release of Firefox 57 (late November) we are primed for WebExtensions, the new, improved architecture for add-ons in Firefox. As of Firefox 57, add-ons are sealed off from each other more effectively and are no longer capable of accessing deeper layers of the browser. The security issue in combination with Mailvelope and the popular open-source browser that came to light last May will thus be resolved.
Yet, not only security has benefited: Mailvelope now utilizes the latest version v2.5 from OpenPGP.js. On the one hand, the performance of encryption operations has been increased, on the other hand, improved compatibility with OpenPGP Standard has been achieved. This will decrease the likelihood of errors when messages or keys are exchanged with other PGP applications.
Also the user interface has seen improvements in Mailvelope 2.0. Major parts of it have been rewritten with the React UI Library. This migration will facilitate better maintenance of the projected further development by larger development teams. Another asset of Mailvelope 2.0: The Mailvelope UI components are now shown more efficiently in the pages of the respective webmailers. Handling Mailvelope has thus become significantly more fluent.
As developers of an extremely security-relevant browser extension, we rely on the solid security architecture of the browser that we support. We therefore highly appreciate the changeover to WebExtensions by Firefox.
Thanks to the fact that Mozilla‘s WebExtensions and Google‘s Chrome Extensions provide a nearly identical environment for developers, not only the development of Mailvelope, but also that of extensions by other developers will be significantly easier and faster.
For the user, that means: Faster updates and swift further development of new features because there is no more need for inconveniently adapting Mailvelope to the different architectures of two different browsers.
The major part of the changes to Mailvelope 2.0 is of technical nature and will not immediately be apparent to the user. Innovations concerning ease of use and simplified user guidance for setup and operation of Mailvelope will be realized especially in future versions. Yet, marked improvement is brought by Mailvelope 2.0 to those who need to send large attachments. The size limit for the encryption of attachments has been raised to 50 MB. Above that, Mailvelope now supports the GPG binary format (*.gpg files) for decryption and encryption.
We are in the possession of a security audit that was requested by the email provider Posteo and conducted by Cure53, which has revealed that the Firefox security structure is currently unable to offer a sufficiently safe environment for the Mailvelope browser extension.
As has been obvious for some time, Firefox architecture does not seal off add-ons from each other sufficiently enough. However, the fact that, in some extreme cases, even private keys of a Mailvelope user can be compromised had not been proved yet. Cure53 has now been able to demonstrate that such an attack is feasible: Either, the user has to be tricked into installing a malicious add-on or the attacker manages to take over an already installed add-on.
Mailvelope naturally relies on the security of the underlying browser platform. In the present case, we are unable to offer a remedy ourselves. Nevertheless, Mozilla is already working on a fundamental improvement of the add-on system. In November 2017, Firefox is scheduled to finally switch to an overhauled add-on structure, which will then offer sufficient protection against attacks.
A new Mailvelope version for the new, improved Firefox structure is already in the making.
Until Mozilla has modified the architecture, the following safety recommendations apply:
The security audit also demonstrated some positive results regarding Mailvelope. Posteo writes about this:
There was a check made as to whether email providers for which Mailvelope is used could access a Mailvelope user’s private keys saved in the browser – this was not possible. All other attempts made by the security engineers to access private keys saved in Mailvelope, such as operating third party websites or man-in-the-middle attacks, were also unsuccessful.
Security Audits such as the one performed by Posteo serve as an important indicator that shows how we can further improve Mailvelope. At this point, we’d like to thank Posteo for conducting the audit and thus their contribution to the Mailvelope project.
Improving the user experience of PGP is a key factor for wider adoption of email encryption. One of the major obstacles is the key exchange. If a manual key exchange is required before starting a secure communication with PGP, the barrier is often too high. This is shown by studies like "Why Johnny still can't encrypt".
The success of the Signal protocol, which is or will be used by almost all big players in the messenger market, reminds us that a deployment of end-to-end encryption is possible for billions of users.
But not with a manual key management, or as Matthew Green has put it in his post "What’s the matter with PGP?":
Manual key management is a mug's game. Transparent (or at least translucent) key management is the hallmark of every successful end-to-end secure encryption system. Now often this does involve some tradeoffs -- e.g., the need to trust a central authority to distribute keys -- but even this level of security would be lightyears better than the current situation with webmail.
In this post we want to present our approach to transparent key management and further user experience improvements.
Mailvelope v1.5.0 focuses on improving the user experience in several key areas.
Google Mail and Google App users no longer need to enter recipient email addresses twice.
Mailvelope will read recipient addresses from the webmail UI when opening the editor to write encrypted messages. If the user adds or removes additional recipients, those will be transferred back to the webmail UI as well. Support for other webmail providers is planned.
If both the recipient and the sender are using the current release of Mailvelope, they will no longer need to exchange public keys manually.
When writing a new message, public keys will be fetched automatically while typing in recipient email addresses. This will work for any Mailvelope user that has verified their email address using the current version.
While we would like to improve the usability for as many users as we can, we also understand that some users might not want auto-lookup and key upload to be enabled.
This new and improved user experience is fueled by a new piece of technology that we are excited to share today. We’ve built a simply key server that works similarly to the Signal backend. It verifies email addresses using an encrypted verification email. This not only verifies email address ownership but also provides cryptographic proof of private key ownership.
You can learn more about our key server at keys.mailvelope.com. The code is licensed under the AGPL v3.0 and is developed completely in the open on GitHub. If you’re a developer you can also learn more about the API in the documentation.
We want to make it as easy as possible to write encrypted email between users of different platforms and form factors. That’s why we’re excited to announce that we are working together with GPGTools for macOS to make it completely painless to write encrypted email between our users. GPGTools is in the process of integrating the Mailvelope Key Server and will also be providing an automatic key lookup user experience.
In addition, we are gathering feedback for the key server from the PGP community at the OpenPGP Summit in July.
The recently published version 1.4 of Mailvelope comes with new features for encrypting files. A search function allows now to import keys from public key servers.
With the file encryption feature of Mailvelope you can encrypt files on your hard drive according to the PGP standard. In the same way as email encryption, the files will be encrypted with the public key of the receiver.
More details can be found in the Documentation File Encryption.
Email providers that directly integrate Mailvelope into their email application will support encrypted email attachments automatically. For email providers like Gmail™, Yahoo™ or Outlook.com™ there are restrictions in the Mailvelope editor and encrypted attachments are not directly supported. With the availability of file encryption Mailvelope offers an alternative: encrypting email attachments can now be done manually.
A search field in the Mailvelope key management area simplifies the search on public key servers. Keys can directly be imported from the search results of the key server.
More information on the search functionality in the Documentation Key Handling.
The two major German email providers GMX and WEB.DE today announced the availability of PGP encryption based on Mailvelope. A great deal of development efforts was put into the Mailvelope Open Source Project over the past 12 months resulting from the collaboration between 1und1 and Mailvelope GmbH, and as of today, the 30 million clients subscribing with GMX and WEB.de can start using the integrated End-to-End encryption for the first time.
The groundbreaking convergence of browser extension and web application has reached an unparalleled degree of user friendliness without compromising security. That way, Mailvelope contributes significantly in making secure communication a viable and attractive solution for the everyday user.
Using a Mailvelope API (Application Programming Interface) that is basically utilizable for other providers, secure containers inside the GMX and WEB.DE email clients are generated, within which PGP messages (and file attachments) can be read and generated. The user is able to identify the Mailvelope containers through an individual security backdrop at any given moment, and at no time will confidential data reach the Mail provider without encryption.
This is where Mailvelope stands out from server-side PGP-solutions such as OX Guard / mailbox.org. These may contribute to a further prevalence of PGP, but they cannot be regarded as End-to-End Encryption: the private key is on the server; the messages are encrypted and decrypted directly at the provider, which is why the User always needs to rely on the server and the provider. The contention that this is a protection against unsafe end devices falls short of the issue it is trying to address because when using this approach, the message and the files arrive at the end device without encryption in each instance, which is why the security of the data always depends on the quality of the end device. The server-side approach makes for centralized structures that constitute potentially worthwhile targets for attacks.
Mailvelope addresses the issue of assigning the private key to several end devices through a generated 26-digit retrieval code. This code is generated on initial setup in an optional step and will then be entered by the User on all other devices. Following, the private key can be synchronized from the cloud. The package containing the private key has a strong encryption (AES-256) and can only be opened using the 26-digit randomized password. This encryption has a very high level of security and, according to current knowledge, will not be vulnerable to cracking beyond 2030. Experts in the field agree that the weak spots of any system concerning secure communication are not found in current algorithms such as AES, or, like Snowden has put it, “Encryption works“.
After initial setup, mobile devices such as the iOS and Android apps by GMX and WEB.DE can be used for PGP encryption. In this case, also the contacts (public keys) of the User are synchronized. Once a contact has been added (with optional fingerprint verification) to Mailvelope, it will then automatically be synchronized to other devices. To accomplish that, Mailvelope taps provider-neutral formats.
Today, the two German telecom providers Deutsche Telekom and United Internet (1und1, Web.de, GMX.de) announced to provide end-to-end encryption for users of De-Mail. The Mailvelope browser extension will be integrated into the De-Mail webmail client and be used for all PGP related encryption services. In the last months we have worked together with 1und1 and Deutsche Telekom on this integration to improve the usability of PGP in a webmail environment and at the same time enforcing strong boundaries between browser extension and De-Mail web server.
The Mailvelope browser extension is available for Google Chrome since 2012. In its current mode of operation PGP capabilities are added to the frontend of supported webmail providers. The advantage of this approach is that all encryption relevant services and the key storage are encapsulated in a locally installed browser extension which is isolated from the webmail client.
To integrate with the De-Mail system Mailvelope developed a client API that further improves usability and adds features like encrypted attachments. Mailvelope's secured user interface components can be seamlessly embedded into web applications. The API is open, documented and available for review in our GitHub repository.
We are excited to partner with the DE-Mail alliance and bring end-to-end encryption to a wider audience.
Mailvelope v0.8.0 is now based on a new version of OpenPGP.js after a major redesign of the library. With its modular design, a new high level API, improved compatibility to the OpenPGP standard and various other improvements we now have a solid foundation for the future development of Mailvelope.
In February 2014 Cure53 conducted an audit of the complete code base of OpenPGP.js. The penetration test yielded an overall of 26 issues. All critical, high and medium issues have been fixed. The complete report and status of the bug fixing can be found in the OpenPGP.js wiki. We continue to disclose all security audits to provide best possible transparency in our development process. See here also statement from OTF on "Bringing Openness to Security".
Spoofing of cleartext signed messages: Mailvelope does not support verification of cleartext signed messages as of now and therefore was never vulnerable to this attack.
EME-PKCS1-v1_5 padding with weak random numbers: messages sent with Mailvelope prior to v0.8.0 are vulnerable to the "known padding" (aka "stereotyped message") case, an attack to recover the encrypted message is possible due to Coppersmith. However, the attack is only feasible if the used RSA key meets a certain "at-risk" condition:
An RSA encryption key is at risk if its modulus size is >= 256 times its public exponent. This condition is not met by most PGP keys. Probably fewer than 1/1000 PGP keys are "at-risk".Trevor Perrin, OTF Red Team
The complete analysis on the EME-PKCS1-v1_5 padding bug is available in the Mailvelope wiki.
Keys generated with Mailvelope have a higher exponent and are therefore "safe". Also the found numbers suggest that RSA keys generated with most modern software after the year 2000 are not in a risk condition.
The risk is further mitigated by the fact that, for Mailvelope on Google Chrome, a recovery of the padding is only possible for messages created within the same browser session. That means, given a target message from a "at-risk" key, an attacker requires the padding from a second regularly decrypted message created in the same browser session as the target message.
The Mailvelope editor now allows the signing of messages.
Make now a backup of your keyring with the Export all keys feature.
Thanks go to all contributors of release v0.8.0, especially to the Open Technology Fund (RFA) for sponsoring the project. The Cure53 team for the thorough review and the improvements brought to OpenPGP.js. Also thanks to Trevor Perrin for further security analysis and assistance.
More than seven months have passed since our last major release, and today we are excited to announce the availability of Mailvelope v0.7.0.
The performance of the key grid has been optimized in order to reduce the initial loading time and allow the handling of a large number of keys. The key import function has undergone a complete rewrite and now provides a better logging mechanism for warnings and errors during the import process.
One way to exchange keys is by email. When the public key as armored text is part of the email body, Mailvelope can detect the key and mark it with an overlay as is the case with encrypted messages:
On clicking, the Mailvelope options dialog opens and the key is automatically imported.
Work on the Firefox version of Mailvelope has progressed and the feature set is now almost identical to the Chrome extension. Only the decrypt inline scenario is currently not feasible due to technical limitations. Instead, the Firefox add-on will always display decrypted messages in a pop-up window. Also, the performance needs further improvements before we can officially release the Firefox add-on.
Find the latest packages for both platforms in the releases section on GitHub.
Among others, Mailvelope now generates 2048-bit RSA keys by default, fixes wrong encoding of non-ASCII characters in messages and adds a reference to Mailvelope in the PGP header comment. See changelog for a complete list of changes.
Mailvelope v0.7.0 for Chrome is now available in the Chrome Web Store.
Mailvelope v0.6 is released today with a major redesign focusing on security. An audit done by Cure53 started end of December 2012 and evaluated Mailvelope’s security implementation and its security design aspects. In the course of two months we worked together with Cure53 on new concepts to prevent any form of leak of sensitive user data and at the same time do not degrade the user experience. The complete penetration report may be reviewed here.
Highlights of this new release include:
See also the security section in the documentation for more details.
We would like to thank the Open Technology Fund (RFA) for sponsoring the security audit. Without this funding the optimizations in the new release of Mailvelope would not have been possible. Thanks go also to Mario Heiderich and Krzysztof Kotowicz from Cure53 for their contributions.