request - support for encrypted volumes

[williamkray]

This is definitely an enhancement feature, but I would love some sort of native ability to encrypt all the volumes used for data storage (mail, SOGo calendar/contact data), and only decrypt them when accessed. This can currently be accomplished by using encrypted partitions, but this leaves the data exposed once the partition is mounted, and requires interaction to decrypt in the event of a reboot or similar lifecycle event. Ideally, this should be accomplished as a part of the mailcow suite similar to how protonmail behaves.

Using asymmetric encryption seems like it might be feasible from the technical side, as the incoming messages would be able to encrypt messages at-rest without needing the private key. The trickier side of things would be decryption, and any time an app were launched, it would require a decryption password or something in order to unlock the private key temporarily.

I believe dovecot has some support for this natively (EDIT: via this plugin https://wiki2.dovecot.org/Plugins/MailCrypt), but I have no idea what would be required to implement. Obviously this would also cause problems with third-party applications connecting over IMAP as they wouldn't be able to decrypt the data. In the case of Protonmail, the solution is to write a separate bridge application that mail apps connect through, but obviously I'm not expecting that part to be included in this project.

[williamkray]

aha, i see that encryption of the messages themselves is already default (per https://github.com/mailcow/mailcow-dockerized/issues/1876) so clearly there's something else happening already to enable encryption/decryption in the MTA. however, if the data is exposed then it means so is the volume with the encryption key, so having a password encrypted storage mechanism would still be a feature request.

[Jakob-Szuk]

You may be able to remove the private key from the server file system once dovecot is booted into ram. If the server has to reboot, you will need to manually reinstate the private key until fully booted.

This is dependent on sufficiently clearing the key from memory to prevent attacker from discovering potentially from memory dump.

This comment needs further verification.

However may be best practice procedure.

The following may be helpful (however regarding the 'lazy' solution of leaving a private key in a third party keystore for automatic reloading of privatekey via api as failover, is poor practice, and frankly is the mxadmin's role is to be on call 24 hours a day for this primary task).

For posterity, in case the below blog goes offline, it is pasted in full, and followed by part one of the series on this topic:

https://blog.onefellow.com/post/173796677183/how-to-obfuscate-dovecot-encryption-key

How to obfuscate dovecot encryption key

Perhaps you read my blog post about server side email encryption and you are wondering how to protect secret key from leaking with your data. There are probably dozen ways to do this, but i will describe one that i particularly like.

I am talking about removing private key from server at all…or at last from it’s file system. Idea is as follow: after dovecot start, we remove private key from disk. Private key is still loaded into system memory but it is not on disk anymore, and access to it via memory dumps is limited (at last on OpenBSD). Anyway, access to the key is much harder then simple copy&paste. Add to it some nice obfuscate procedure and you are good to go. There is one problem: how to load that key when restart of the process is needed or server reboot happens…

Maybe you heard about Authy Two-factor app and service. Among pretty standard features related to 2FA they support very nice feature: OneTouch. It replace entering numbers to simply approving/declining requests. This feature is very important if you are away from server console.

Next you will need some kind of keystore, in this case it can be some remote server with ssh/scp allowed from dovecot machine. On the keystore server you will need to install onetouch-ssh - this will talk via API to Authy servers. You will need to setup all that manually, and there is no shortcuts.

here, how it looks on diagram

https://66.media.tumblr.com/8ca561ae4f86c824d0116099a711b136/tumblr_inline_p9t6diaWVl1rc7j75_500.png

New stuff there: Dovecot_Wrapper, yeah this is another thing needed, once Authy account is set, app installed on the phone and onetouch-ssh works on keystore, you have to put wrapper script over rc dovecot startup script.

Let’s see what Dovecot_Wrapper do. First it passes all the init functions to original rc script except one related to stop/start daemon. When this call is intercepted, it make scp connection to the keystore using trusted ssh-keys, keystore (dcu) then send login request to the phone where admin see the command and can take action (approve/decline). If timeout happen or request is declined - key cannot be accessed and copied to dovecot machine, Dovecot_Wrapper bails-out as dovecot wont start without private key.

When approved, private key is copied to dovecot machine - it can be copied on the disc or to temporary MFS, or whatever you want. After verify that key hash is correct, dovecot can start now. If all is OK, we can now remove private key off the server by wiping it out (remember to use special command like rm -P, not just rm - to prevent restoring it from filesystem). You can now perform nice obfuscation by replacing original key with some newly generated - just remember to place it exactly in the spot where old one was. Do not worry - this key won’t be used by dovecot process.

While this is not very elaborate, removing key from server and obfuscation protect your encrypted mails from being accessed by many occasions:

fs dumps are useless as data is encrypted and there is no key to decrypt
potential RCE that lead to data leackage is limited or not possible - no key on server, attacker see only encrypted data
cloud provider backups are safe - same - no key, no access
perhaps many more…

This is just one of the techniques that “naively” protects your data - by “naively” - i mean - there are no solid ways to protect your data - you can only make life harder for hackers (but just imagine the face of the guy who pwned your mail server and see later that all he has is fake key and GBs of encrypted data) This was posted 7 months ago. It has 0 notes.

Part 1:

https://blog.onefellow.com/post/167267172603/server-side-email-encryption-with-dovecot

Server side email encryption with Dovecot

If you are running custom mail server in order to protect users privacy and security it is good idea to encrypt local mailstore. Finally we have good way of doing that (yeah there were trees before, but usually admins want something that is maintained by core team) and it is mail-crypt plugin for Dovecot.

Setup is easy and will take you 5 minutes, first create keypair, here i am using todays reasonable encryption settings for ECC:

create private key used for decrypting mail:

openssl ecparam -name prime256v1 -genkey | openssl pkey -out master.key;chmod 0400 master.key

create public part out of private key used for encryption:

openssl pkey -in master.key -pubout -out master.pub

optionaly you can protect keypair from accidental damage by setting immutable flags (OpenBSD):

chflags schg,uchg master.pub chflags schg,uchg master.key

configure plugin in dovecot.conf:

mail_plugins = $mail_plugins mail_crypt plugin { mail_crypt_global_private_key = </etc/dovecot/crypt/master.key mail_crypt_global_public_key = </etc/dovecot/crypt/master.pub mail_crypt_curve = prime256v1 mail_crypt_save_version = 2 }

do not forget to add mail_crypt to any protocols you are using in your local config, like:

protocol imap { mail_plugins = "mail_crypt notify imap_zlib" }

restart server and all new mail will be encrypted by default.

OK, so what about old mails? According to Dovecot developers, supported way of encrypting mails is to move them around (like move from folder to folder), but that’s just, ehhh.. So i wrote simple script that will make your life easier. You can use it to encrypt all old mails. Setup is easy, you need to update your magic(5) database (usually some /etc/magic file) by adding this lines:

0 string CRYPTED MailCrypt

script is on my gist, please read it before usage. Updating magic is nessesery to avoid double encryption if you re-run it. And remember - always backup your data! I take no resposibility if you loos anything using this script.

Usage: encrypt_maildir.sh user directory example: encrypt_maildir.sh john_doe .MyShoppingMails

Mail folders are encrypted one-by-one, and with the “progress-bar”, so you will know where you are. I have used it to encrypt ten of thousands of email messages and so far no problems there.

Now, if you are wondering how this mail encryption give you advantage in case server breach (if someone gain root access) then i say, it give you nothing as private key for decryption reside on the server itself, so it is easy to decrypt all e-mails once bad guy get there. There is one solution for this, and i will write how to do it in next blog post. Stay tuned… This was posted 1 year ago. It has 1 note.

Perhaps a feature request could be therefore be framed in support of implementing pgp.js within sogo.

PM may be based on AfterLogic WebMailPro with some fancy UX styling. WMP uses opensource pgp.js in the client, as does PM. However, as AL appears on US soil, and probably its servers, there is no guarantee that it would not have a backdoor injected into it at any stage. Therefore the opportunity would be for a European based development (eg mailcow) to offer pgp.js as competition and as failover for the time if or when WMP pgp.js code gets backdoored. Notwithstanding it is far easier to target email in the wild (during transit) as opposed to leaving fingerprints in code of any major actor having tampered with code.

William, I think your concern about intrusion security may be reasonably valid, and as server encryption may or may not be best addressed directly by the Mailcow projec?t; the inclusion of pgp.js in the SOGo client may be a valid suggestion, as William has discussed the PM pgp.js bridge. There is a wordpress plugin that enables the same pgp.js code to encrypt mail in the browser with the sender's private key before sending browser-pgp-encrypted form mail across tls and storing in pgp format in your own email account. So if a wp plugin dev could implement the code, and even kim dotcom on mega.nz; then pgp.js should be devisible for SOGo. Hopefully this should be an expected future update, however, mailsystems today should be secure by design at the outset, and developments such as introduction of pgp.js should be published in the project milestones ahead of time. The good thing with MC being developed in Germany is that Deutschland is a hotspot of mail encryption experts, and this development should be easily / rapidly feasible now that pgp.js has become well developed.

Should anyone with pgp.js experience read this, then it may be an opportunity to initiate a fork of SOGo as a project.

Notwithstanding the waiting for pgp.js in SoGo, Mailcow is a valuable 5 Star contribution to the usability of server management as AX, and UX. 5 stars.

William has valid security questions needing address, and would be valuable if others can chime in on this topic, as well as being a flag for now implementing pgp.js, and given that all the UN countries did unanimously declare online privacy (meaning fundamental security of information systems) is a Human Right, and in Europe as in any UN country, implementation of server systems that do not have comprehensive security measures in place could be seen as a liability of breach of Human Rights.

For private server admins, the purpose of administrating privately includes accessing enhanced assurance of this Human Right, and therefore without having the team of experts that Mailcow Managed Service has, pgp.js would be a reasonable step in making security more available and easier to access.

In support for the grounds for implementing such; the following resolution was universally enacted in response to the 2013 email crisis, and email server security is an implied term. The GDPR results from the below UN resolution, and which explicitly obliges security, in general, and particularly if a sysadmin lets others use an email system either for profit or not.

May it be proposed that pgp.js be added to SOGo as a priority to bring the system into expected safety standards.

The General Assembly,

Reaffirming the purposes and principles of the Charter of the United Nations,

Reaffirming also the human rights and fundamental freedoms enshrined in the Universal Declaration of Human Rights and relevant international human rights treaties, including the International Covenant on Civil and Political Rights and the International Covenant on Economic, Social and Cultural Rights,2

Reaffirming further the Vienna Declaration and Programme of Action,

Noting that the rapid pace of technological development enables individuals all over the world to use new information and communication technologies and at the same time enhances the capacity of governments, companies and individuals to undertake surveillance, interception and data collection, which may violate or abuse human rights, in particular the right to privacy, as set out in article 12 of the Universal Declaration of Human Rights and article 17 of the International Covenant on Civil and Political Rights, and is therefore an issue of increasing concern,

Reaffirming the human right to privacy, according to which no one shall be subjected to arbitrary or unlawful interference with his or her privacy, family, home or correspondence, and the right to the protection of the law against such interference, and recognizing that the exercise of the right to privacy is important for the realization of the right to freedom of expression and to hold opinions without interference, and is one of the foundations of a democratic society,

Stressing the importance of the full respect for the freedom to seek, receive and impart information, including the fundamental importance of access to information and democratic participation,

Welcoming the report of the Special Rapporteur on the promotion and protection of the right to freedom of opinion and expression, submitted to the Human Rights Council at its twenty-third session, on the implications of State surveillance of communications on the exercise of the human rights to privacy and to freedom of opinion and expression,

Emphasizing that unlawful or arbitrary surveillance and/or interception of communications, as well as unlawful or arbitrary collection of personal data, as highly intrusive acts, violate the rights to privacy and to freedom of expression and may contradict the tenets of a democratic society,

Noting that while concerns about public security may justify the gathering and protection of certain sensitive information, States must ensure full compliance with their obligations under international human rights law,

Deeply concerned at the negative impact that surveillance and/or interception of communications, including extraterritorial surveillance and/or interception of communications, as well as the collection of personal data, in particular when carried out on a mass scale, may have on the exercise and enjoyment of human rights,

Reaffirming that States must ensure that any measures taken to combat terrorism are in compliance with their obligations under international law, in particular international human rights, refugee and humanitarian law,

1.  Reaffirms the right to privacy, according to which no one shall be subjected to arbitrary or unlawful interference with his or her privacy, family, home or correspondence, and the right to the protection of the law against such interference, as set out in article 12 of the Universal Declaration of Human Rights1 and article 17 of the International Covenant on Civil and Political Rights;2

2.  Recognizes the global and open nature of the Internet and the rapid advancement in information and communications technologies as a driving force in accelerating progress towards development in its various forms;

3.  Affirms that the same rights that people have offline must also be protected online, including the right to privacy;

4.  Calls upon all States: 

(a) To respect and protect the right to privacy, including in the context of digital communication;

(b) To take measures to put an end to violations of those rights and to create the conditions to prevent such violations, including by ensuring that relevant national legislation complies with their obligations under international human rights law;

(c) To review their procedures, practices and legislation regarding the surveillance of communications, their interception and the collection of personal data, including mass surveillance, interception and collection, with a view to upholding the right to privacy by ensuring the full and effective implementation of all their obligations under international human rights law;

(d) To establish or maintain existing independent, effective domestic oversight mechanisms capable of ensuring transparency, as appropriate, and accountability for State surveillance of communications, their interception and the collection of personal data;

5.  Requests the United Nations High Commissioner for Human Rights to submit a report on the protection and promotion of the right to privacy in the context of domestic and extraterritorial surveillance and/or the interception of digital communications and the collection of personal data, including on a mass scale, to the Human Rights Council at its twenty-seventh session and to the General Assembly at its sixty-ninth session, with views and recommendations, to be considered by Member States;

6.  Decides to examine the question at its sixty-ninth session, under the sub‑item entitled “Human rights questions, including alternative approaches for improving the effective enjoyment of human rights and fundamental freedoms” of the item entitled “Promotion and protection of human rights”.

70th plenary meeting
18 December 2013

[Jakob-Szuk]

With Sogo, which is developed by Inverse in Canada, fully opensource; it may not be feasible to implement the above security measure unless the standard memcached is excluded in the stack. Sogo uses this to lighten the load on Apache auth for user keys. Accessing memcached stored keys could be a blackhat vector, but if your server is private and low load then you might be able to do away with memcached if there is any risk of pw hash exfiltration?

/"Caching SOGo uses memcached to cache results of your authentication sources and storage database, lightning the load on the resources."/ https://sogo.nu/about.html#/features

[Jakob-Szuk]

Sogo offers SMIME certificate encryption, however:

On May 13th 2018, the Electronic Frontier Foundation (EFF) announced critical vulnerabilities in S/MIME, together with an obsolete form of PGP that is still used in many email clients[3]. Dubbed EFAIL, this is a particularly critical hit to S/MIME that will require significant coordinated effort by many vendors to fix[4]. https://en.wikipedia.org/wiki/S/MIME#Security_Issues

Therefore it is important to note that while SMIME is incomparable to the self-provisioned and therefore authentic self-generated keys; it may appear that SMIME may now be deprecated and offer nil security within SOGO.

Lack of search results suggest SMIME vulnerability may still be a problem, and it is relevant that SMIME is insufficient compared with PGP.

Therefore negating the validity of Sogo if wishing to access email security.

PGP would need to be sent through mailcow from another client such as thunderbird. If security is a main aspect of setting up a mail server then Sogo may not be what one is looking for, despite pretty appearances.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.