Re: [Mailman-Developers] GSOC Project idea: OpenPGP integration
On 25.04.2013 21:10, Abhilash Raj wrote:
Abhilash, i don't see any mention in your proposal of how you plan to deal with the secret key material. will there be a way for mailman to use a secret key that is stored in a password-protected form? If so, how?
Well I am not quite proficient in cryptography but I tried to answer how could it be done and have updated on the same link[1]. Here is a copy of only that part:
One of the biggest issues of any cryptographic procedure is to secure and manage the keys. Firstly for the lists, when the list is created by the owner the keypair is generated by mailman in some time(because when i was trying to create one using gnupg, it asked me to wait for sometime and keep doing some work to get threshold entropy. Although in reality I don't have much idea about how the keys are created, but I am guessing that it somewhere uses the random bits from the memory of the host where key is created and thus required a threshold entropy for the proper randomization of the key. On virtualised Linux systems, this can often be achieved by installing the rng-tools package.) and is stored in the database against the name of the list. It will then be available for download to the
May I suggest that mailman doesn't create the list key by itself, but ask the list maintainer to upload a public/private key pair (if no crypto hardware is used, see below)? On a virtualized system, getting real randomness is tricky.
subscribers. [python-gnupg][2] also allows one to encrypt/decrypt using the keys that are protected by a paraphrase. Such paraphrase though would then be stored in cleartext format in database. Though this poses a security thread but even if you encrypt and store the paraphrase, you can only slow the process of decryption once the server is compromised since the private-paraphrase-encryption key will also be needed to be stored somewhere on the local disk.
I would distinguish the following two scenarios:
The list is not-so-high-sec that you can risk storing the secret key without a password (which is the equivalent to storing the passphrase in the database).
Your list has elevated security requirements. In this case, you can use gpg-agent to manage the secret key (and its passphrase). This would require the sysadmin to start the gpg-agent and enter the list's passphrase before firing up mailman (or mailman could queue incoming mails until the secret key becomes available). This would open you the option to have the mailing list's secret key on a hardware token (e.g. the CryptoStick http://shop.kernelconcepts.de/product_info.php?cPath=1_26&products_id=133).
Stefan.
Stefan Schlott writes:
- Your list has elevated security requirements. In this case, you can use gpg-agent to manage the secret key (and its passphrase).
I don't understand what threat you propose to address in this way. It's true that you can prevent the attacker from getting access to the key (using agent forwarding or a token, it need not be on the exposed host at all), but we're assuming he has access to the host and the Mailman process.
At a minimum you need some kind of privilege separation mechanism within Mailman. I'd recommend a postfix-style separate process which does all cryptographic work. But this might be a very large performance hit.
On 04/27/2013 12:45 PM, Stephen J. Turnbull wrote:
Stefan Schlott writes:
- Your list has elevated security requirements. In this case, you can use gpg-agent to manage the secret key (and its passphrase).
I don't understand what threat you propose to address in this way. It's true that you can prevent the attacker from getting access to the key (using agent forwarding or a token, it need not be on the exposed host at all), but we're assuming he has access to the host and the Mailman process.
If mailman is storing messages on-disk in an encrypted form, Stefan's proposal mitigates the threat of an adversary with offline access to the disk (e.g. in the event of server theft or seizure) -- no additional message content will be revealed if such an adversary scrapes the contents of the disk.
--dkgDaniel Kahn Gillmor writes:
If mailman is storing messages on-disk in an encrypted form, Stefan's proposal mitigates the threat of an adversary with offline access to the disk (e.g. in the event of server theft or seizure)
OK, it does that.
But in the event of that kind of threat, I think you also need to protect the logs and lists. I guess you can deal with the logs by the simple expedient of not keeping them.
On 27.04.2013 06:45, Stephen J. Turnbull wrote:
- Your list has elevated security requirements. In this case, you can use gpg-agent to manage the secret key (and its passphrase).
I don't understand what threat you propose to address in this way. It's true that you can prevent the attacker from getting access to the key (using agent forwarding or a token, it need not be on the exposed host at all), but we're assuming he has access to the host and the Mailman process.
The gpg-agent approach protects you from all storage-related attacks:
- unencrypted backups
- physical access to the harddrive
- etc.
It does not protect from attackers who have access to the contents of the computer's RAM:
- raw memory access and scanning for the secret key (requires root)
- memory dump via DMA-enabled interfaces (firewire, pc-card, ...)
- cold boot attacks
Stefan.
I don't think that "we" have the expertise to create a "secure" system. At best, we can adopt good practices and provide an obscured traffic stream. I consider anything more to be beyond the scope of the MM project.
On Apr 27, 2013, at 8:22 AM, Stefan Schlott <stefan.schlott@ulm.ccc.de> wrote:
On 27.04.2013 06:45, Stephen J. Turnbull wrote:
- Your list has elevated security requirements. In this case, you can use gpg-agent to manage the secret key (and its passphrase).
I don't understand what threat you propose to address in this way. It's true that you can prevent the attacker from getting access to the key (using agent forwarding or a token, it need not be on the exposed host at all), but we're assuming he has access to the host and the Mailman process.
The gpg-agent approach protects you from all storage-related attacks:
- unencrypted backups
- physical access to the harddrive
- etc.
It does not protect from attackers who have access to the contents of the computer's RAM:
- raw memory access and scanning for the secret key (requires root)
- memory dump via DMA-enabled interfaces (firewire, pc-card, ...)
- cold boot attacks
Stefan
On 27 Apr 2013, at 14:40, Richard Wackerbarth <rkw@dataplex.net> wrote:
I don't think that "we" have the expertise to create a "secure" system. At best, we can adopt good practices and provide an obscured traffic stream. I consider anything more to be beyond the scope of the MM project.
Also, what kind of secure list would have automated processing of message content as a requirement? If a message is gpg encrypted, then every sender would require the public keys of every recipient, would they not? Which means that a PKI for the list holders is required. Currently outside of Mailman's scope, but if it exists, then presumably senders would be required to cryptographically sign every message. All the list needs to do is verify the signature before redistributing. THAT is going to be the main body processing requirement.
On Apr 27, 2013, at 8:22 AM, Stefan Schlott <stefan.schlott@ulm.ccc.de> wrote:
On 27.04.2013 06:45, Stephen J. Turnbull wrote:
- Your list has elevated security requirements. In this case, you can use gpg-agent to manage the secret key (and its passphrase).
I don't understand what threat you propose to address in this way. It's true that you can prevent the attacker from getting access to the key (using agent forwarding or a token, it need not be on the exposed host at all), but we're assuming he has access to the host and the Mailman process.
The gpg-agent approach protects you from all storage-related attacks:
- unencrypted backups
- physical access to the harddrive
- etc.
It does not protect from attackers who have access to the contents of the computer's RAM:
- raw memory access and scanning for the secret key (requires root)
- memory dump via DMA-enabled interfaces (firewire, pc-card, ...)
- cold boot attacks
Stefan
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/iane%40sussex.ac.u...
Security Policy: http://wiki.list.org/x/QIA9
-- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148
On 29.04.2013 11:40, Ian Eiloart wrote:
Also, what kind of secure list would have automated processing of message content as a requirement?
imho you're asking the wrong question ;-) _All_ network communication should be encrypted, it is a pity that mail encryption is so little adopted.
If a message is gpg encrypted, then every sender would require the public keys of every recipient, would they not?
No. The idea here that the recipient of a mail sent to a mailing list is the (trusted) mailman server, thus the only key needed is the mailing list public key. Mailman has access to its secret key, decrypts the incoming message and re-encrypts it for each recipient.
Stefan.
Ian Eiloart writes:
Also, what kind of secure list would have automated processing of message content as a requirement?
Precisely, a list that wants to avoid this requirement:
If a message is gpg encrypted, then every sender would require the public keys of every recipient, would they not?
The idea is that senders use the list's public key. The list holds those public keys, and uses them to re-encrypt the message on a recipient-by-recipient basis after decrypting with its own private key.
The discussion has been about how to deal with attacks on (a) the list's private key (including offline attacks on the hard drive) and on (b) the temporarily decrypted text (which could end up in the clear for a long time in a queue file or if Mailman crashes).
Also, what kind of secure list would have automated processing of message content as a requirement? If a message is gpg encrypted, then every sender would require the public keys of every recipient, would they not? Which means that a PKI for the list holders is required. Currently outside of Mailman's scope, but if it exists, then presumably senders would be required to cryptographically sign every message. All the list needs to do is verify the signature before redistributing. THAT is going to be the main body processing requirement. That is one way, the other is you send the message encrypted to the
On 4/29/13 5:40 AM, Ian Eiloart wrote: list's public key, and the list decrypts the message and then reencrypts to each recipient's public key. (In many cases this doesn't actually require decrypting/reencrypting the whole message, just the session key block).
The list could also check any signature, and sign messages with valid signatures with it's key.
That way, subscribers don't need any other subscriber's public key. In fact, I think the list could even be set up anonymous so you might not even know who anyone else was, just that the list has validated that the message came from someone on the list.
-- Richard Damon
participants (7)
-
Daniel Kahn Gillmor -
Ian Eiloart -
Richard Damon -
Richard Wackerbarth -
Stefan Schlott -
Stefan Schlott -
Stephen J. Turnbull