From 993e51edb91b0d743a6284ff68a1c21b6d5e8604 Mon Sep 17 00:00:00 2001 From: Silvio Rhatto Date: Fri, 19 Apr 2013 14:53:05 -0300 Subject: Adding index.mdwn --- index.mdwn | 311 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 311 insertions(+) create mode 100644 index.mdwn (limited to 'index.mdwn') diff --git a/index.mdwn b/index.mdwn new file mode 100644 index 0000000..2ead33c --- /dev/null +++ b/index.mdwn @@ -0,0 +1,311 @@ + + ffff + ff firma - + ffff encrypted mailing list manager + ff - a firma cai mas nao quebra + ff + +Index +----- + + 1 - The concept + 2 - Everyone has the private key X The server has the private key + 3 - Why bash + 4 - Development Guidelines + 5 - Setup + 6 - Tips + 7 - Design and features + 8 - Caveats + 9 - Contact + +The concept +----------- + + In portuguese, "firma" means for signature, signature and trust checking and + is a slang for strength and enterprise. + + 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 strength 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 an + email message in its input, grab the encrypted/signed message, re-encrypt + and send it to each subscriber. + + In the server you just need the script, a keyring with the list keypair + and two config files. 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 first there are some options: + + - Schleuder + http://schleuder2.nadir.org/ + + - GPG Mailman + http://medien.informatik.uni-ulm.de/~stefan/gpg-mailman.xhtml + + - Crypt-ML - gpg-ezmlm + http://www.synacklabs.net/projects/crypt-ml/ + + - Secure Email List Services (SELS) + http://sels.ncsa.illinois.edu/ + + For the second option there is the NAH6 Mailman patch, + http://mail.python.org/pipermail/mailman-coders/2003-June/000506.html + + For the firsts releases of Firma, we choose to use just the first option. + In the future the code should contain support for an one-keypair list, + but this is not the main behavior we want in an encrypted mailing list. + This is a question of centralized versus decentralized vulnerability. + + An one-keypair list is more or less just like a mail alias: someone + send an encrypted email to the list address and the manager just forwards + that encrypted email to the lists subscribers, optionally removing some + headers and performing some security auditing. Every user has the list + private key, so if someone lost it to the world then one must regenerate + a keypair and send again to every subscriber. + + In the case of a keypair stored in the server, where subscribers has just + the list pubkey, the list admin just need to remove the correspondent pubkey + from the list's keyring with in case some user has its keypair compromised. + + These two approaches has a similar external hole of some private key turned + public. Designing Firma, we decided for the centralized model, for three main + reasons: + + 1 - A server can be safer than any user's ordinary computer. + + 2 - Automation: when some user is removed from the list, we just remove their + key from the list keyring; in the decentralized approach, the list admin + needs to regenerate a new list keypair, otherwise the unsubscribed user + can still decrypt list messages if he can sniff the mail server traffic. + + 3 - Use a public-key and all info stored onto it as the subscriber info. + +Why Bash +-------- + + You may ask why we choose 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 against cracks such as rootkits. + + - Keeping your encrypted 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. + + - Firma adopted the style suggested in the Advanced Bash-Scripting Guide, + http://www.tldp.org/LDP/abs/html/scrstyle.html + +Development Guidelines +---------------------- + + As a security project we made a restricted set of guidelines / design policy, + attempting to get a clean, bug-free and high quality code. We choose a slow + development rather than sit-and-code. These rules are detailed in the file + GUIDELINES. + +Setup +----- + + Note for Debian users: you'll need the "expect" package to run firma. + + Firma installation is quite simple: + + 1 - Create a folder to store lists; by default firma use /var/lib/firma/lists + but you can use anything, just edit firma and change FIRMA_LIST_PATH + variable. + + 2 - Copy firma script to whatever you like, e.g. /usr/local/bin and check that + it has no write permission + + 3 - Create a list-wide config file (default is /var/lib/firma/firma.conf) with + the common definitions for all lists. You might just copy the sample + firma.conf.dist and edit according to your needs. + + All config variables can be overwritten at each list's own config file; + firma.conf should be chmoded as 600, chowned nobody.nobody or whatever + user your MTA runs. If you run postfix, the user is specified by the + main.cf parameter "default_privs". + + For a list of all config parameters, type + + firma --help config + + 4 - Then create your lists with the command + + firma -c your-list + + Then firma will ask some questions and create a gpg keyring and a config + file with the following variables: + + LIST_ADDRESS= list's email address + LIST_ADMIN= list's administrators email addresses (space separated) + LIST_HOMEDIR= list's GnuPG homedir, where the list's keyrings are located + PASSPHRASE= passphrase for the list's private keyring + + Then a gpg keypair and a config file are automatically generated; + 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. + + After that you can add some optional parameters on this list config file: + + SUBJECT_PREFIX= prefix to be included in the subject of list messages + + REMOVE_THESE_HEADERS= headers that should be stripped from list messages + (space separated case-insensitive entries) + (may include regexps (e.g., X-.*) + + REPLIES_SHOULD_GO_TO_LIST= set to '1' to add a Reply-To header containing the + list address + + SILENTLY_DISCARD_INVALID_MESSAGES= set to '1' to silently discard invalid + messages (message not signed/encrypted, + sender not subscribed to the list, etc.) + instead of sending bounces back to sender + + KEYSERVER= default keyserver to import/export keys + (defaults to keyserver.noreply.org) + + REQUIRE_SIGNATURE= whether messages sent to the list should be (1) or don't + need to be (0) signed to be processed; defaults to '1'; + this doesn't affect the way email administration works, + when signature is mandatory + + For a list of all config parameters, type + + firma --help config + + 5 - 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 -e your-list" + + and then run the command + + newaliases + + alternatively, you can use a virtual mailbox table if you want + to easily host a lot of encrypted mailing lists. + + 6 - Admin tasks are performed through aliases like your-list-request@yourmachine + or via command-line: + + firma -a your-list + + inside this command or encrypted in your mailing list request, use the + following commands: + + sub keyserver|keyfile key-id + + subscribe key-id pubkey from file or keyserver (currently not + implemented) + + unsub email-address + + unsubscribe all keys with email-address IDs (currently not + implemented) + + use email-address + + uses the given address for message delivery instead + of the primary address of a subscribed key + + 7 - To subscribe and unsubscribe manually the users and the list admins on, use + a command line like + + gpg --homedir [path-to-your-list-keyring] --import < file + + and be sure that after this command the list keyring is owned by nobody.nobody. + + 8 - 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 is shutdown + - Use a big PASSPHRASE, 25+ chars with alpha-numeric and special ascii keys + +Design and features (OUTDATED) +------------------- + + Firma is simple but its simplicity doesn't 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 don't want to deal with + unencrypted content + + - All unwanted email headers are striped as a privacy measure for who sends + the message + + - Firma doesn't 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 removes 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 + +8 - Caveats + + People that uses Sylpheed should config the list to accept messages that + arent signed. Thats because currently firma depends that the encrypted + and signed parts come in the same PGP block and Sylpheed splits the + encrypted message and the signature in two separate blocks. Thats a + firma and not Sylpheed issue. The PGP/MIME spec allows one to send + the PGP/MIME encrypted message in two separate blocks. We hope to fix + this someday :) + +9 - Contact + + Contact: firma (@) firma.sarava.org + + Messages should be encrypted with the list pubkey + 3DF104314023E18358EFDD270D51B4E79E693CF7 found at keys.indymedia.org. + -- cgit v1.2.3