Does anyone have any experience with this that can provide a review and/or advice? TIA.
http://non-gnu.uvt.nl/mailman-pgp-smime/
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Hello
Am 11.02.21 um 19:24 schrieb Dennis Putnam:
Does anyone have any experience with this that can provide a review and/or advice? TIA.
- From the site itself: "Beware! This code has not been touched since 2010-09. Therefore, it's mainly obsolete.
DO NOT USE THIS CODE"
- In my experience the main problem is not to decrypt and encrypt emails, it is to get the public keys of your users and keep your private keys valid.
For a public encrypted mailing list server you need an S/MIME certificate *and* an PGP certificate for each list. That is, because you usually can not restrict users to one method or the other, and they are not compatible. Especially S/MIME certificates expire after some time (yearly, or up to 5 years). Your PGP certificates should expire too, for security reasons. You need to keep them both up to date with overlapping new certificates. And you need to distribute their public keys to your users.
Then you need to know the preferred encryption method of each user plus their public keys. Those will change too, therefore you need some mechanism to get the current one and keep them in sync. And make sure, to never use expired ones.
Kind regards, Christian Mack
-- Christian Mack Mailinglisten-Administration Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung & Lehre 78457 Konstanz, Deutschland ++49 7531 88 4416
Hi Christian,
On 2/12/2021 5:01 AM, Mailman-admin wrote:
Hello
Am 11.02.21 um 19:24 schrieb Dennis Putnam:
Does anyone have any experience with this that can provide a review and/or advice? TIA.
- From the site itself: "Beware! This code has not been touched since 2010-09. Therefore, it's mainly obsolete.
DO NOT USE THIS CODE"
- In my experience the main problem is not to decrypt and encrypt emails, it is to get the public keys of your users and keep your private keys valid.
For a public encrypted mailing list server you need an S/MIME certificate *and* an PGP certificate for each list. That is, because you usually can not restrict users to one method or the other, and they are not compatible. Especially S/MIME certificates expire after some time (yearly, or up to 5 years). Your PGP certificates should expire too, for security reasons. You need to keep them both up to date with overlapping new certificates. And you need to distribute their public keys to your users.
Then you need to know the preferred encryption method of each user plus their public keys. Those will change too, therefore you need some mechanism to get the current one and keep them in sync. And make sure, to never use expired ones.
Kind regards, Christian Mack
Thanks for that info. None of it sounds insurmountable other than the code itself. If I need a secure mailman list, is there another alternative?
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On Fri, Feb 12, 2021 at 10:11:20AM -0500, Dennis Putnam wrote:
If I need a secure mailman list, is there another alternative?
You may want to give some thought to, and to then specify in a follow-up in this thread, what you mean by "secure" in this context.
For example, you might want security properties such as:
Every message sent to the list can be authenticated by its recipients.
Every message sent to the list is robustly encrypted to prevent its being readable by non-members.
For the property/ies above to be immune to rogue CAs.
Some combination of the above.
It may be helpful to ask yourself: what is your threat model?
Also, which key distribution mechanisms are available to you? (For instance: are the list members able to meet in person for key exchange?)
-- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing?
() ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Hi Sam,
On 2/13/2021 3:18 PM, Sam Kuper wrote:
On Fri, Feb 12, 2021 at 10:11:20AM -0500, Dennis Putnam wrote:
If I need a secure mailman list, is there another alternative? You may want to give some thought to, and to then specify in a follow-up in this thread, what you mean by "secure" in this context.
For example, you might want security properties such as:
Every message sent to the list can be authenticated by its recipients.
Every message sent to the list is robustly encrypted to prevent its being readable by non-members.
For the property/ies above to be immune to rogue CAs.
Some combination of the above.
It may be helpful to ask yourself: what is your threat model?
Also, which key distribution mechanisms are available to you? (For instance: are the list members able to meet in person for key exchange?)
I'm looking to decrypt incoming email from subscribers and encrypt outgoing to each. The threat model is to not have any email into or out of the mailing list to be intercepted/monitored.
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On Sun, Feb 14, 2021 at 10:58:01AM -0500, Dennis Putnam wrote:
I'm looking to decrypt incoming email from subscribers and encrypt outgoing to each. The threat model is to not have any email into or out of the mailing list to be intercepted/monitored.
The two sentences imply different requirements.
Even if you satisfy the requirements in the first sentence, any attacker on the wire will be able to capture ("monitor") the emails; and the headers will be in plain-text (including the Subject header, sender, and recipients), even if the body and attachments are encrypted: https://ssd.eff.org/en/module/why-metadata-matters
Also, if the attacker has compromised the CA, then they will potentially be able to decrypt S/MIME messages (but not OpenPGP messages, if the encryption and key generation were well-implemented[1]).
If you really want to satisfy the requirements in the second sentence, then you might want to look at DIME (aka Darkmail), mixers, or alternatives to email:
[1] At least, not unless affordable quantum computing is available to the attacker. If it is, then you would also need to use a quantum-resistant cipher. Unfortunately, doing that is still very inconvenient to do using GnuPG or similar.
-- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing?
() ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Hi Sam,
On 2/14/2021 11:26 AM, Sam Kuper wrote:
On Sun, Feb 14, 2021 at 10:58:01AM -0500, Dennis Putnam wrote:
I'm looking to decrypt incoming email from subscribers and encrypt outgoing to each. The threat model is to not have any email into or out of the mailing list to be intercepted/monitored. The two sentences imply different requirements.
Even if you satisfy the requirements in the first sentence, any attacker on the wire will be able to capture ("monitor") the emails; and the headers will be in plain-text (including the Subject header, sender, and recipients), even if the body and attachments are encrypted: https://ssd.eff.org/en/module/why-metadata-matters
Also, if the attacker has compromised the CA, then they will potentially be able to decrypt S/MIME messages (but not OpenPGP messages, if the encryption and key generation were well-implemented[1]).
If you really want to satisfy the requirements in the second sentence, then you might want to look at DIME (aka Darkmail), mixers, or alternatives to email:
[1] At least, not unless affordable quantum computing is available to the attacker. If it is, then you would also need to use a quantum-resistant cipher. Unfortunately, doing that is still very inconvenient to do using GnuPG or similar.
Thanks for the info. It is not the headers that I care about but rather the email content. I also would not care about S/MIME as all my subscribers will be GPG. I thought that was essentially the obsolete code did. I was considering taking that plug-in and modifying it to at least work with GPG and mailman 2.1.36.
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On 2/14/21 3:02 PM, Dennis Putnam wrote:
I was considering taking that plug-in and modifying it to at least work with GPG and mailman 2.1.36.
You might look to see if you can move the problem to the MTA level. E.g. have the MTA, or something like a milter on it's behalf, encrypt outgoing messages.
You can probably have something decrypt the messages between the MTA and Mailman.
Something like this would allow you to use a stock Mailman.
-- Grant. . . . unix || die
participants (4)
-
Dennis Putnam -
Grant Taylor -
Mailman-admin -
Sam Kuper