Fossa Guard Pro goes free

Fossa Team decided to contribute a small piece to public security making pro version of S/MIME web extension for Gmail freely available for all kind of use.

Fossa Guard Pro 1.0.3 is available at Chrome Web store supports only Chrome and has a rich set of features like

• hidden subject, 
• local search inside encrypted messages 
• ... more info at our Blog 

Fossa Guard Free version is also available at Chrome Web store and has experimental support for Firefox, Yandex including their mobile versions.

Please note that Fossa server and Fossa certificates won't be available in both versions, so you can use S/MIME certificates frpom other vendors or use self-signed.

Since 2016 it was a great journey for us making this solution robust and capable to address secure emailing using S/MIME standard.

For the moment we officially stop any activities on the project though continue to support users.

Thanks for all who supported and gave interest (among them were  companies like Google, PWC, Greenpeace).

If you have any clarifications or questions please email us to: fossa.guard@gmail.com

2020 year summary

2020 was not an easy year for business communications when most conversations switched online causing growing email volumes and rising breach risk due to stressed employees' mistakes.

Fossa Team, realizing the importance of safe and secure email exchange for doing business in social isolation conditions continuously improved the S/MIME extension for Gmail and finally officially released V1.0 of Pro edition.

The list of features and improvements:

• Hidden subject via rfc822 wrapping supported by Outlook and Thunderbird
• Ability to switch existing email thread into S/MIME via the dedicated toolbar
• S/MIME signed only support avoiding MIME parts repacking by Gmail servers 
• User certificates availability and validity details with in-place certificate import from a file or Fossa registry
• Option to auto-index S/MIME messages while User decrypt and read them 
• Usability improvements including the ability to minimize Compose / View window

Below you can find detailed explanations with screenshots.

We are sure that the 2021 year continues requesting more security and safety for email conversations so we will eager to improve Fossa solution availability and usability focusing on our customers' primary needs.

Hidden subject 

An ability while composing S/MIME message to hide the Subject and Recipient's name (leaving only email address) by wrapping the original message using content-type message/rfc822 and encrypting it leaving Google the bare minimum of metadata.

Note that Outlook and Thunderbird support this ability right from the box. So Fossa team is again using only industry proved solutions keeping compatibility.

Ability to switch existing email thread into S/MIME|

Each email is now supplied with a Fossa bar containing buttons for Reply All, Reply, Forward options in S/MIME format which makes a copy of the email into the Fossa Compose window making it possible to switch conversation into S/MIME signed and encrypted format.

Note that for S/MIME messages the bar contains buttons: 

• Decrypt - to view the original message of S/MIME encrypted

                        

• View Original Message - to view S/MIME signed with signature details

                        

S/MIME signed support

It has been for a while we thought about how to avoid Google mail servers mangling S/MIME signed only emails because after the repacking of MIME entities and restricting access to S/MIME signature any validation becomes useless.

We noticed the difference in how Google mail servers change S/MIME signed only emails and decided to implement a different approach for emails to *@gmail.com and other addresses.

For internal Gmail addresses, we use multipart/mixed content type with the original S/MIME signed message as an attachment, so that Fossa Guard extensions was able to parse it validate the signature of the original message.

More details can be found here: https://fossaguard.blogspot.com/2020/06/fossa-guard-pro-10-smime-signed-support.html

User certificates details

When composing a S/MIME message in addition to color indication for an email address it's helpful to know what User you're addressing and what certificates (and their validity) are available for him.

This information is now available in the popup available by the click on the email address pillow.

Note that it's possible in-place to:

• Upload a new certificate from a file or 
• Add a corresponding one from the Fossa certificates registry 

                             

Auto-indexing 

In addition to search in S/MIME encrypted emails via local index, we introduced an option to auto-index S/MIME emails while reading improving usability. 

User Interface improvements

• Roboto font has become a default font to be aligned with Gmail appearance.
• Compose window now can be minimized not blocking access to Gmail.
• The local search index is represented by a bar demonstrating how many does it takes in available memory.

Here is the Fossa Guard Pro V1.0 playlist with videos demonstrating the above functionality: 

Web extension vs Web application security considerations

Below we would like to list considerations about web extension security that we consider important while implementing end-to-end email encryption comparing with traditional web applications.

Delivery model. Authenticity. 

Web extension delivery is controlled by the end-user who can:

• Install web extension from the store (Chrome web store, Firefox Add-ons, ...) delegating the store owner checking authenticity, security, privacy policy.
• Install web extension manually verifying its authenticity and security using corresponding scanners and utilities
• Get web extension as preinstalled with the corporate version of the browser. 

NOTE that in a web application case, the user doesn’t have control over the webserver that is providing the web application, any web service provider can potentially provide a malicious version that could compromise the encryption. 

It's valid for webmail encryption services like ProtonMail, Tutanota, ...

Fine-grained permissions 

Web extensions have a permissions model to give users fine-grained control over what information and resources could be accessed by any extensions they install. 

Each extension comes packaged with a list of permissions, which govern access to the browser APIs and web domains. If an extension has a core vulnerability, the attacker will only gain access to the permissions the vulnerable extension already has.

Privilege separation

Extensions are built from two types of components, which are isolated from each other - content scripts and extension cores. Content scripts interact with websites and execute with no privileges. Extension cores do not directly interact with websites and execute with the extension's full privileges.

Process Isolation

From Protecting Browsers from Extension Vulnerabilities: 

"Each component of the extension runs in a different process. The extension core and the native binary each receive dedicated processes. Content scripts run in the same process as their associated web pages. 

This process isolation has two benefits: it defends against browser errors and low-level exploits. 

Process isolation helps protect the extension core from browser implementation errors, such as cross-origin JavaScript capability leaks because JavaScript objects cannot leak from one process to
another. 

Process isolation also defends against low-level exploits in the browser. For example, if a malicious web site operator manages to corrupt the renderer process (e.g., via a buffer overflow), the attacker will not be granted access to the extension APIs because the extension core resides in another process."

Web extension isolated world

Important to note that the extension's content script runs in an isolated world. "Isolated worlds do not allow for content scripts, the extension, and the web page to access any variables or functions created by the others. This also gives content scripts the ability to enable functionality that should not be accessible to the web page" [2]

Moreover, the extension's content script is completely cut off from the background script (an invisible page that holds the main logic of the extension)  and can communicate with it only via Chrome messages https://developer.chrome.com/extensions/messaging. So that message content can be validated and sanitized in a favor of security.

Vulnerability analysis

Web extensions have more privileges thus vulnerabilities in browser extensions put users at risk by providing a way for website and network attackers to gain access to users' private data and credentials.

Following researches like An Evaluation of the Google Chrome Extension Security Architecture browser vendors improve web extensions platform security regularly at the same time making extension developers publish and follow strict data privacy policies.

Fossa Guard Pro 1.0.3 Hidden Subject support

Fossa Guard Pro V1.0.3 supports an option to hide the Subject and Recipient's name (leaving only email address) by wrapping the original message using content-type message/rfc822 and encrypting it.

New checkbox 'Hide Subject' is available once you select to Encrypt the message 

The subject is hidden under generic 'Confidential Email' and looks like an empty message with encrypted attachment 'smime.p7m'

In Outlook this message is represented by a message with an internal original message S/MIME encrypted and signed

Check the video demonstrating it.

Link to the extension: Fossa Guard Pro V1.0.3 

Fossa Guard Pro 1.0 Personal Certificate enrollment options

Once Fossa Guard Pro 1.0 installed User has to enroll his Identity - Personal Certificate to start secured emailing. The enrollment procedure artifacts are stored into the local Chrome extension storage within userspace (see https://fossaguard.blogspot.com/2020/03/technical-details-about-chrome-extension.html for details) and consists of:

• Private Key - you should keep privately and use to 
• decrypt messages sent to you 
• sign messages so that your recipients will be able to verify the signature using your Public Certificate 
• Trusted Certificates - a chain of officially Trusted certificates that issued the Public Certificate from direct Issuer up to the Root Trusted Certificate so that anyone can verify the origin of your Public Certificate.
• Public Certificate - the certificate your recipients should use to encrypt private messages sent to you, this certificate is also used when you're sending an encrypted message to yourself, thus it's present in Personal and in Recipient lists of certificates.

There are three main options to enroll the Personal Certificate once Fossa Guard is installed.

Import Private Key (p12, pfx)

The option valid when the User already has got a personal identity in the form of a file P12 or PFX format protected by a Passphrase (can be empty). Usually, it contains a Private Key accompanied by a corresponding Public Certificate. 

Once the user provides the correct passphrase to decrypt the imported file, Fossa Guard:

• Checks if contained Public Certificate is valid and is issued to the email of logged User, if Yes - the Private Key assigned as the default User's identity 
• Adds the corresponding certificate to Recipients list (so the user will be able to send encrypted emails to himself)

NOTE that there are few or no vendors providing free trusted S/MIME identities: http://kb.mozillazine.org/Getting_an_SMIME_certificate

Enroll Fossa Certificate

The user has an option to enroll a free Personal Certificate signed by Fossa Certificate Authority (CA). Fossa Guard extension and Fossa CA designed to make the enrollment simple and secure using Enrollment over Secure Transport (EST).
Once the user provides the name (the only mandatory parameter) he can start the procedure

The pair Private / Public Keys and Certificate Signing Request (CSR) are generated locally in the browser.

On the next step, the User should log in to Fossa Server (by clicking `Get Shared Secret from Fossa.me Server`) to get a shared secret which will be used to establish a TLS connection. Please note that you should log in to the Fossa Server using the same Gmail user to get the shared secret for the corresponding email address.

Using TLS connection Fossa Guard securely sends Certificate Request with Public Key inside and gets back Public Certificate signed by Fossa CA

On the final step, Fossa Guard asks the User to enter Passphrase to protect Private Key before storing it with Public Certificate in local Chrome extension storage.

That's all, Fossa Guard is ready for secure mailing via Gmail.

Enroll Self-signed Certificate

Self-signed Personal Certificate enrollment procedure has only the first and last steps from Fossa certificate enrollment.
On completion self-signed certificate is automatically added to the Personal, Trusted, and Recipient certificates list.

NOTE that self-signed certificates can't be verified checking Issuer certificates, so the user should find the trusted way to share it with his recipients.

Fossa Guard Pro 1.0 Settings overview

Fossa Guard settings page contains three corresponding lists:

• Personal Certificates - list represents Private Keys for the User. There are three main options to add them:
• Import Private Key (p12, pfx) - via P12 or PFX file protected by a Passphrase (can be empty)
• Enroll Fossa Certificate - via enrollment procedure when the certificate is securely signed on Fossa Server
• Enroll Self-signed Certificate - via fully local enrollment procedure
• Trusted certificates - list of Certificate Authorities (CA) Certificates officially trusted by main vendors, usually openly published on vendor sites. Fossa Guard has preloaded trusted certificate for the following identity vendors:
• Comodo
• DigiCert
• Fossa.me 
• Global Sign
• WISE Key
• Recipients certificates contain public certificates of your recipients including your own.

Users can import additional Trusted and Recipient certificates via a file in PEM or DER formats.

NOTE that Self-signed certificates are recognized and proposed to be added into both lists Trusted and Recipients

By click on Certificate name User can view certificate details

Fossa Guard Pro 1.0 S/MIME signed support

Send S/MIME signed message

Gmail mangles S/MIME signed messages differently http://fossaguard.blogspot.com/2020/04/smime-signed-messages-support-in-gmail.html

• application/pkcs7-mime with SignedData by restricting access to the signature (since G Suite uses this format to sign messages)
• multipart/signed by rearranging MIME parts of the message converting to multipart/mixed

The following approach has been implemented to send S/MIME signed emails:

• to *@gmail.com addresses multipart/mixed format used with smime.p7m attachment which contains original S/MIME multipart/signed message with signature due to the following reasons:
  • User will be able to see message content, files without any extension
  • User will be able to view content, files of the original message with the digital signature using of Fossa Guard
• to all other addresses a standard S/MIME SignedData format due to the following reasons:
• G Suite accounts use custom domains, 
• G Suite uses SignedData format internally for S/MIME signed messages
• Gmail doesn't mangle message to external addresses

Signature status indication

When User opens S/MIME signed message in Gmail UI Fossa Gard extension tries to verify the signature 

Once S/MIME signature verified the corresponding status is indicated. 

Fossa Guard replaces the content of the message by the original read from smime.p7m attachment. 

A new button `View Original  Message` becomes available to open the email in Fossa Guard View dialog with original message content and original attachments

Signature verification 

• The attached certificate chain is not used in the email signature verification procedure until added to the list of trusted. 
• Email signature verification is performed per email Sent date.