Table of Contents

Secure remailer

Secure remailer
founder: ruza
depends on:
interested: sachy
software license: -
hardware license: -

~~META: status = active &relation firstimage = :project:gnupg.png ~~

Motivation

We have an contact email where people can send sensitive info. We dont want to transfer such info unsecurely nor have stored anywhere where can be leaked later. This email addres is actually an alias whose membership is changing overtime. Only actual final recipients (ie brmlab council members) should be able to decrypt such email.

Solutions

GnuPG email/ML gateway

Explore existing solutions like Ciphermail or similar.

New idea

recipient changes GPG keys validity Usage/purpose
contact email practically none GnuPG master key longtime
i.e. 10 years
sign subkeys
actual recipients once a year or so GnuPG subkey generated once a year,
valid for 15 months
could be revoked prematurely
recipients to decrypt email messages
Architecture components
Email client

An email client of the sender. Since we are expecting an heterogenous environment that consist of different email clients “public subkey distribution” evolves to be a known requirement or we could say a problem to be solved. An email client generates an email content in the following forms:

Receiving email server

Email/SMTP server is receiving emails from email clients and encrypts them eventually (depending on the form of an email received). Following inputs are assumed:

Mailing list archive

Emails are stored in the email archive in a decrypted form. Since there is no requirement to reencrypt emails to the specific recepients an email archive is the only reason to hold private subkey on the receiving server.

Access to the email archive is possible via an HTTPS protected web interface (data transfer security) and managed by assigning user rights in such web interface (confidentiality).

Authentication and autorization to the data archived on the filesystem level are realized using operating system user rights assignment and SSH remote access capabilities. Also possible access to the raw data by the virtual infrastructure provider should not be forgotten.

Recipients

Recipient group consist of an organization board members or another small similarly defined user group. For the managing simplicity we didnt choose the way to reencrypt each incoming email to specific list of recipients instead of simply distribute private subkey to the recipients.

Recipient always receives an mailing list processed emails in the form of GnuPG encrypted email and using private subkey to decrypt such email.

As we know in our situation (brmlab council mailing list) consist of:

Master keypair owners

Master keypair is not used in a day-to-day operation. Its purpose is to be a source of trust in case new subkey is released. Limited number of persons (“master key holders/owners”) should be established (probably a couple). His/her role and responsibility is to hold whole keypair in a secure way, issue and distribute newly created subkey to the recipient group at the at the right time and do the appropriate steps in case some subkeys should be matter of a revocation.

Known problems

Old idea

Due to a change in the idea on implementation and architecture the following text needs to be reworked or proclaimed as not selected as a solution to be implemented.

Sender encrypts an email against Brmlab public GPG key. Email is delivered to an brmlab SMTP server, reencrypted by GPG-remailer to an up-to-date list of recipients (that is changed more frequently than contact email) and resent to them. Only actual and specific members can decrypt such message with his/her own private key.

GPG for contact email has been generated: Brmlab GPG key

All email aliases that should be reencrypted are directed to one OS user:

/etc/aliases
confidential: secmail
join:           secmail

Per user delivery using procmail:

~secmail/.forward
|/usr/bin/procmail

Each email alias has an own configuration file for GPG-remailer.

~secmail/.gpg-remailer-secmail
logfile: remailer.log
loglevel: 0
debug: true
nomail: false 
replyto: <rada@brmlab.cz>
member: member01@somewhe.re
member: member02@elsewhe.re
member: member02@nowhe.re
clear-text: rejected       
signature:  absent
recipient: members

Corŕect configuration file is chosen by procmail parsing mechanism. Here we are also generating reject messages if messages seems to be not encrypted.

~secmail/.procmailrc
SHELL=/bin/sh
LOCKFILE=$HOME/.lockfile.lock
LOGFILE=$HOME/procmail.log
LOGABSTRACT=yes
UMASK=007
VERBOSE=yes
SUBJECT=`formail -x Subject:`
TO=`formail -x To: `
FROM=`formail -x From:`
 
# copy of all incoming emails for debugging purposes
:0c
{
        :0Bfw
        * !(-----(BEGIN|END) PGP MESSAGE-----)
        | formail -I "Subject: [unencrypted and not delivered to $TO]$SUBJECT"
 
        :0
        ! ruza@ruza.eu
}
 
# rejects all non-encrypted emails
:0B
        * !(-----(BEGIN|END) PGP MESSAGE-----)
        | ( formail -r -a "X-Brm: Rejected from $TO";\
        echo "This is an auto-generated reply.";\
        echo " ";\
        echo "Your e-mail";\
        echo "To: $TO";\
        echo "Subject:$SUBJECT ";\
        echo " ";\
        echo "was REJECTED and NOT DELIVERED because";\
        echo "this address accepts GnuPG ENCRYPTED emails only.";\
        echo " ";\
        echo "SEND your email AGAIN:";\
        echo " 1) encrypted by GPG/PGP (https://www.gnupg.org/) to $TO or";\
        echo " 2) unencrypted to unsecure@brmlab.cz";\
        echo " ";\
        echo "Or You can ask for help at rada@brmlab.cz";\
        echo ""; ) | /usr/sbin/sendmail -t -oi -f "$TO"
 
# gpg-remailer drops original From, so its added by this filter to Subject
:0 cfw
        | formail -I "Subject: [$FROM] $SUBJECT"
 
# re-encrypt email
:0
        * ^(To|Cc|Bcc):.*secmail@brmlab.cz.*
        | /usr/bin/gpg-remailer /var/lib/secmail/.gpg-remailer-secmail
 
:0
        * ^(To|Cc|Bcc):.*join@brmlab.cz.*
        | /usr/bin/gpg-remailer /var/lib/secmail/.gpg-remailer-secmail