1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
|
ffff
ff firma -
ffff encrypted mailing list manager
ff - a firma cai mas nao quebra
ff
The concept
-----------
In portuguese, "firma" means for signature, signature and trust checking and
is a slang for strenght and enteprise.
All this together just can be one thing: an encrypted mailing list manager :P
In the streets, the expression "a firma cai mas nao quebra" (the enterprise
falls but does not breaks) is commonly used to talk about the strenght of a
group that operates in secrecy. To our list manager, this concept says that
your encrypted mailing list can stops to work -- if the server goes offline
or abducted by aliens -- but the system can never be broken. With firma, we
are trying to follow this philosophy.
Firma is based on the gpgmailalias.pl perl script, hosted at
http://www.rediris.es/app/pgplist/index.en.html, but completely rewritten
in bash.
Firma works as a command line and MTA pipe alias tool that receives a
email message in its input, grab the encrypted and signed message and
re-encrypt and send it to each subscriber.
In the server you just need the script, a keyring with the list keypair
and a config file. When mail arrives, it is redirected by the MTA to the
script and it process the message if its properly encrypted and signed.
No temporary files are written during a message processing and no default
message archive, so no messages -- encrypted or not -- rest on your system
in all steps of the process.
Everyone has the private key X The server has the private key
-------------------------------------------------------------
When using a encrypted mailing list software, one must choose between
keeping the private key in the server or send it to each of the
subscribers. We'll not consider the case where every subscribers encrypt
the message to all recipients cause this has none automation in the
process we are looking for.
For the second option we have the NAH6 Mailman patch,
http://mail.python.org/pipermail/mailman-coders/2003-June/000506.html
For the first we have GPG Mailman,
http://medien.informatik.uni-ulm.de/~stefan/gpg-mailman.xhtml
This is a question of centralized versus descentralized vulnerability.
- descentralized means just an alias for incoming encrypted email
- if some user has its keypair compromissed, the list admin just need
to remove the correspondent pubkey from the list's keyring
Why Bash
--------
You may ask why we choosed bash. Its really strange a crypto project using
shell scripting language. But bash has many advantages:
- Bash is found in almost all unix-like systems
- Small dependencies: firma needs just tools like sed, awk, grep, cut and
gpg itself. Look at the file "GUIDELINES" to see a complete list of all
unix commands needed to run firma.
- You can easily put all the tools, scripts and config files in a read-only
media to protect againt cracks such as rootkits.
- Keeping your encripted list manager out from a huge and sometimes bugged
mail software prevents insecure use of your mailing list by an excess of
unwanted functions and routines.
- Firma has a total KISS design, and bash helps to keep it simple.
Setup
-----
Firma installation is quite simple:
1 - create a folder to store lists; by default firma use /usr/local/etc/lists
but you can use anything, just edit firma and change FIRMA_LIST_PATH
variable.
2 - copy firma script to whatever you like, eg. /usr/local/bin and check that
it has no write permission
3 - then create your lists with the command
firma -c your-list
this will ask some questions and create a gpg keyring and a config file
with the following variables:
MAIL= path for sendmail or any smtp wrapper (eg, /usr/lib/sendmail)
MAIL_ARGS= command line arguments to the smtp wrapper
GPG= path for gnupg binary (eg, /usr/bin/gpg)
LISTNAME= list email (eg, firma@domain.tld)
LISTADMIN= list administrator email addresses (space separated)
GPGDIR= gpg dir for the lists' keyring
PASSWD= passwd for the lists' keyring
then a gpg keypair and a config file are created. the owner of the config
file and keyring should be nobody.nobody (or the user your MTA run as) and its
permissions must be 600.
4 - create an alias to the list at your MTA; on sendmail or postfix,
add this to your aliases file:
your-list: "| /usr/local/bin/firma -p your-list"
your-list-request: "| /usr/local/bin/firma -r your-list"
and then run the command
newaliases
5 - to subscribe the users and the list admins on the list, use ...
6 - send encrypted AND signed messages to your-list@yourmachine and look
what happens :)
Tips
----
- Use an encrypted swap memory
- Use a read-only media to store firma and its needed apps
- Use ramdisk to FIRMA_LIST_PATH so all keys and passwords vanishes if the server frozes
- Use a big PASSWD, 25+ chars with alpha-numeric and special ascii keys
Design and features
-------------------
Firma is simple but its simplicity does'nt reflect in lack of design.
- uses a gpg keyring to store both the keys and the subscribers options
- command line is simple to avoid admin tasks resting in some .bash_history
- non-pgp blocks in a message are discarded since we dont want to deal with
unencrypted content
- all unwanted email headers are striped as a privacy measure for who sends
the message
- firma does'nt use any disk write when processing a message; no temp files
that may rest in the system; everything goes in memory (but take care,
sometimes it will use the swap and then is best to make it encrypted)
- by default it doesn't archive messages in the server
- by default it remove the Subject header and put it inside the encrypted
message, as Subject are outside the PGP/MIME context
- messages appear to be sent To: Undisclosed Recipients
Major features are:
- keyring support
- administration through email or command-line
|
