From johny at neuromancer.sk Sun Apr 2 10:01:27 2017 From: johny at neuromancer.sk (Jan Jancar) Date: Sun, 2 Apr 2017 16:01:27 +0200 Subject: [Mailman-Developers] Encrypted mailing lists: Tor project uses Schleuder Message-ID: Hi Mailman Developers. Considering the recent debate on this list regarding the possible uses and usefulness of an encrypted Mailman mailing list, I tried to look for orgs / groups that already use or are looking for an encrypted mailing list. To see what they use / what would they like to use / what required features they need / what nice to haves they might want. My first idea was Tor Project's private mailing lists, they have a few security / organization related lists that are private [1]. They noted my idea was similar to Schleuder, which they started using just recently [2]. I had few other people message me, most use Schleuder [3] and one use of custom patched Sympa installation [4]: > We have a project based on Sympa to integrate PGP support, the backend > is completed and we still have some frontend parts open. We started > with the project some time ago out of frustration of schleuder and > the lack of the userinterface. We choose Sympa because of the high > performance mail processing, however, the frontend is not very nice I think that an organization such as the Tor Project, with their high security requirements, using encrypted mailing lists means that the interest in encrypted mailing lists is well-founded. [1]: https://trac.torproject.org/projects/tor/wiki/doc/emailLists [2]: https://lists.torproject.org/pipermail/tor-project/2017-March/001047.html (and responses) [3]: https://schleuder.nadir.org/ [4]: https://www.sympa.org/ Cheers, -- Jan _________________________________________________ OpenPGP: 362056ADA8F2F4E421565EF87F4A448FE68F329D https://neuromancer.sk -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From raj.abhilash1 at gmail.com Mon Apr 10 08:04:53 2017 From: raj.abhilash1 at gmail.com (Abhilash) Date: Mon, 10 Apr 2017 05:04:53 -0700 Subject: [Mailman-Developers] Deploying mailman3 using containers Message-ID: <53763c01-8b9d-33f6-57b3-7526f1283fc7@gmail.com> Hi All, I have been working for the past two weeks on trying to create a solution to easily deploy Mailman 3 in production. For those interested, you can find the instructions about how to use my work at http://asynchronous.in/docker-mailman/. I have tried to document the process as much as possible. This is still a work in progress, but I have a working deployment[1] using these containers. I try to keep the deployment updated with the github repo, but there is no automated deploy happening there so sometimes it gets out of sync. While this is aimed to finally become a production ready method to deploy mailman 3, it is still not there. All I can say at this point is that it works. I have tried my best to document everything and I keep updating the documentation whenever I feel anything needs more clarity. I would love some feedback to improve the process or documentation. You can open issues on the github repo[2]. Currently, container images are built from the master branch of the gitlab repos and are thus not branded as stable. I am waiting for 3.1 release to add a stable tag to the images. [1]: https://mail.araj.me/ [2]: https://github.com/maxking/mailman -- thanks, Abhilash Raj -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 837 bytes Desc: OpenPGP digital signature URL: From gv at purdue.edu Thu Apr 13 14:18:59 2017 From: gv at purdue.edu (Greg Veldman) Date: Thu, 13 Apr 2017 14:18:59 -0400 Subject: [Mailman-Developers] Patch: Allow definition of a default accept_these_nonmembers list Message-ID: <20170413181859.yohede74gm3itw2b@eclipse.rcac.purdue.edu> Hi, I run a site where it is useful to have a small list of users who should be able to email every list. Rather than manually adding them by hand each time I make a new list, it would be nice to be able to define a value in mm_cfg.py that would get set at create time. The attached patch makes this a configurable item and sets the default to an empty list (as it is now). If you think this is useful functionality, feel free to include this. If not, I'll just throw it out there in case anyone else has the same need and might find it useful. This patch is against version 2.1.23. -- Greg Veldman IT Infrastructure Services, Purdue University gv at purdue.edu | (765)-496-2456 -------------- next part -------------- A non-text attachment was scrubbed... Name: mailman_default_accept.patch Type: text/x-diff Size: 910 bytes Desc: not available URL: From mark at msapiro.net Thu Apr 13 16:30:51 2017 From: mark at msapiro.net (Mark Sapiro) Date: Thu, 13 Apr 2017 13:30:51 -0700 Subject: [Mailman-Developers] Patch: Allow definition of a default accept_these_nonmembers list In-Reply-To: <20170413181859.yohede74gm3itw2b@eclipse.rcac.purdue.edu> References: <20170413181859.yohede74gm3itw2b@eclipse.rcac.purdue.edu> Message-ID: <2b4d5760-732d-2e30-8494-7072c7389a48@msapiro.net> On 04/13/2017 11:18 AM, Greg Veldman wrote: > > I run a site where it is useful to have a small list of users > who should be able to email every list. Rather than manually > adding them by hand each time I make a new list, it would be > nice to be able to define a value in mm_cfg.py that would get > set at create time. The attached patch makes this a configurable > item and sets the default to an empty list (as it is now). Thanks for the suggestion. I don't plan to incorporate it upstream for a couple of reasons. I think it could lead to requests for other DEFAULT_*_THESE_NONMEMBERS settings, some of which might be as useful if not more useful, but mostly, Mailman is already cluttered with too many options making the study of Defaults.py and the ultimate configuration of Mailman a daunting task that many just don't do. Even simple options like this have a cost in making the configuration process more complex. In your specific case, you might find it more maintainable to have a separate list whose only purpose is to be included in accept_these_nonmembers via the @listname syntax, and in any case, it shouldn't be too difficult to script your list creation process to use config_list to populate accept_these_nonmembers. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From rsk at gsp.org Mon Apr 17 19:22:52 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 17 Apr 2017 19:22:52 -0400 Subject: [Mailman-Developers] Encrypted lists predictable difficulties and implementation needs In-Reply-To: <20170319181422.5febb8d9@quill> References: <78383d49-08a8-320a-27d7-cc573cbd28da@forestfield.org> <20170316014746.GA19047@gsp.org> <20836e20-3a1f-57bc-d520-8fa722b3fbc0@forestfield.org> <20170316144626.GC31856@gsp.org> <20170316201003.3dfa529d@quill> <20170318175405.GA32096@gsp.org> <20170319181422.5febb8d9@quill> Message-ID: <20170417232252.GA20725@gsp.org> On Sun, Mar 19, 2017 at 06:14:22PM +0100, Norbert Bollow wrote: > That is true, if the attacker already knows whose communications they > want to snoop on. However one of the main benefit of using encrypted > communications is in the area of making it much more expensive and > politically risky for the attacker to determine which targets have > value. The attacker (for many values of "attacker") is and will be particularly interested in communications that are encrypted -- because they'll stand out. Granted, this will diminish as more communications become encrypted, but for the forseeable future, anyone using encryption or similar privacy measures will be targeted: https://www.wired.com/2014/07/nsa-targets-users-of-privacy-services/ I agree with you that encryption makes it more expensive, and that's an argument for deploying it, but I don't agree that it's politically risky: there are no appreciable consequences for anyone engaging in this. Even at the commercial level (e.g., Verizon's insertion of unblockable cookies in order to conduct surveillance) there are no appreciable consequences for any violation of user privacy or security -- merely inconsequential slap-on-the-wrist fines and then it's right back to business as usual. > In the absence of encryption, that can be achieved by means of mass > surveillance anywhere between the communications endpoints followed by > (possibly AI-based) pattern analysis, at near-zero incremental cost and > near-zero incremental risk per additional group that is subjected to > such surveillance for reasons of its communications being possibly of > interest to the attacker. I almost entirely agree with you on this, but want to point out that if an attacker has compromised an endpoint, they can stop there: there's no need to worry about the rest. And endpoints are already compromised by the hundreds of millions, with more every day. (And as more endpoints become part of the IOT, the rate of compromise will increase drastically.) I think it's quite reasonable to extrapolate a billion compromised endpoints sometime in the next couple of years. (I also think that in a couple of years I'll shake my head at how much of an underestimate that turned out to be.) So if it becomes desirable or profitable for the new owners of those systems to pay specific attention to encrypted mailing list traffic, they will...and probably much quicker than anyone anticipates. They won't get it right the first or second time, just like they didn't get botnet C&C organization right the first or second time -- but it won't take them long to learn. Thus the target end user population for encrypted mailing lists looks something like this: Nobody using freemail providers -- these fall into two categories: those that are owned and those that are going to be owned. Nobody using webmail -- webmail implementations have a long and sad history of serious security issues. And "browser security" is often an oxymoron. Nobody using Windows, MacOS, Android, or iOS. There are already too many exploits on the table to keep track of, and there can be no doubt that these are only a fraction of the total: many more are held by security researchers, vulnerability brokers, intelligence agencies, etc. And Linux probably should be added to that list in the near future, as its increasing deployment has clearly made it an attractive target. (Nod to the past week's releases by the Shadow Brokers, which are surely the tip of the tip of the iceberg.) Nobody with poor email habits, e.g., top-posters, full-quoters, people who use HTML markup. (Since these undercut encryption, sometimes rather badly.) Nobody using the IOT to send or receive email, e.g., their car, which was very likely pre-compromised at the factory. That doesn't leave a lot of people. I'm not saying "don't do it". As an intellectual exercise and a development challenge, it's interesting. I'm saying "make sure -- if people are thinking about deploying this -- that they understand that they have almost no chance of making this work as intended in the real world." ---rsk From nb at bollow.ch Tue Apr 18 05:50:40 2017 From: nb at bollow.ch (Norbert Bollow) Date: Tue, 18 Apr 2017 11:50:40 +0200 Subject: [Mailman-Developers] Encrypted lists predictable difficulties and implementation needs In-Reply-To: <20170417232252.GA20725@gsp.org> References: <78383d49-08a8-320a-27d7-cc573cbd28da@forestfield.org> <20170316014746.GA19047@gsp.org> <20836e20-3a1f-57bc-d520-8fa722b3fbc0@forestfield.org> <20170316144626.GC31856@gsp.org> <20170316201003.3dfa529d@quill> <20170318175405.GA32096@gsp.org> <20170319181422.5febb8d9@quill> <20170417232252.GA20725@gsp.org> Message-ID: <20170418115040.31f57e87@quill> On Mon, 17 Apr 2017 19:22:52 -0400 Rich Kulawiec wrote: > On Sun, Mar 19, 2017 at 06:14:22PM +0100, Norbert Bollow wrote: > > That is true, if the attacker already knows whose communications > > they want to snoop on. However one of the main benefit of using > > encrypted communications is in the area of making it much more > > expensive and politically risky for the attacker to determine which > > targets have value. > > The attacker (for many values of "attacker") is and will be > particularly interested in communications that are encrypted -- > because they'll stand out. Granted, this will diminish as more > communications become encrypted, but for the forseeable future, > anyone using encryption or similar privacy measures will be targeted: > > https://www.wired.com/2014/07/nsa-targets-users-of-privacy-services/ The NSA scans just about all unencrypted email communications anyway. So not encrypting communications certainly is not a viable strategy for ordinary (i.e. non-criminal) people who would like to not have their emails scanned by the NSA. If the NSA were to make the greatest possible efforts in attempts to also scan as many encrypted communications as they can, that could, if they were to achieve 100% success in that regard, in the worst case only bring the level of their privacy violations of encrypted communications up to the level at which they violate privacy for unencrypted communications. Another important point is that not all attackers have capabilities of attacking encrypted communications. An important class of attackers is technically relatively unsophisticated criminals going after relatively soft targets of opportunity. Nota bene, I'm only talking about the communications of non-criminals here. I'm not interested in discussing whether it might be a viable strategy for terrorists or other criminals to intentionally not technically encrypt their communications, in order to attempt to make those communications not stand out among the mass of unencrypted communications among innocents. > I agree with you that encryption makes it more expensive, and that's > an argument for deploying it, but I don't agree that it's politically > risky: there are no appreciable consequences for anyone engaging in > this. I can assure you that "Digital Society Switzerland", a Swiss NGO where I happen to be serving as president, would be most delighted to have concrete evidence of even a single concrete example of a foreign intelligence service having broken into an innocent person's computer or other communication device in Switzerland for purposes of spying on encrypted communications. There are multiple ways in which we would be most eager to exploit this politically, with reputational side effects on the guilty state actor that they would certainly prefer to avoid. Now if the foreign intelligence services deploys their intrusion capability only against terrorists and their close associates, we (Digital Society Switzerland) are not likely to get any evidence of that, and even if we got evidence of such activities, that would not help us politically. But if it should happen that they start mass surveillance of end-to-end encrypted email communications, that would include our internal communications, so the foreign intelligence service would need to compromise a significant number of the devices that we use for communicating, and chances are that one of us would notice that something is wrong, and get the issue addressed in a professional that involves forensic analysis. Even in the case of a foreign state actor that does not care about any diplomatic repercussions, or a foreign state actor that likes to be intentionally provocative, there would be a heavy cost to them if they were to make widespread attacks and these attacks were made widely known, because in such a case the security vulnerabilities that they exploit would become well-publicized, and many of the more interesting surveillance targets would secure their devices against those attacks. > Even at the commercial level (e.g., Verizon's insertion of > unblockable cookies in order to conduct surveillance) there are no > appreciable consequences for any violation of user privacy or > security -- merely inconsequential slap-on-the-wrist fines and then > it's right back to business as usual. Unblockable cookies are quite different technically as well as emotionally/politically from the kinds of attacks that we're discussing here. > > In the absence of encryption, that can be achieved by means of mass > > surveillance anywhere between the communications endpoints followed > > by (possibly AI-based) pattern analysis, at near-zero incremental > > cost and near-zero incremental risk per additional group that is > > subjected to such surveillance for reasons of its communications > > being possibly of interest to the attacker. > > I almost entirely agree with you on this, but want to point out that > if an attacker has compromised an endpoint, they can stop there: > there's no need to worry about the rest. And endpoints are already > compromised by the hundreds of millions, with more every day. (And > as more endpoints become part of the IOT, the rate of compromise will > increase drastically.) I think it's quite reasonable to extrapolate a > billion compromised endpoints sometime in the next couple of years. > (I also think that in a couple of years I'll shake my head at how > much of an underestimate that turned out to be.) All of that is true, although of course even when an endpoint is compromised by one attacker, it may still be inaccessible to other adversaries (e.g. because some of the other adversaries will be less sophisticated, or because the first attacker's rootkit closes the security hole through which they came in, or because the second attacker's rootkit fails to work because it assumes an unmodified system and that assumption is wrong because of the presence of the first attacker's rootkit). > So if it becomes desirable or profitable for the new owners of those > systems to pay specific attention to encrypted mailing list traffic, > they will...and probably much quicker than anyone anticipates. They > won't get it right the first or second time, just like they didn't > get botnet C&C organization right the first or second time -- but it > won't take them long to learn. > > > Thus the target end user population for encrypted mailing lists > looks something like this: > > Nobody using freemail providers -- these fall into two > categories: those that are owned and those that are going to be owned. > > Nobody using webmail -- webmail implementations have a long > and sad history of serious security issues. And "browser > security" is often an oxymoron. > > Nobody using Windows, MacOS, Android, or iOS. There are > already too many exploits on the table to keep track of, and there > can be no doubt that these are only a fraction of the total: many more > are held by security researchers, vulnerability brokers, > intelligence agencies, etc. And Linux probably should be > added to that list in the near future, as its increasing > deployment has clearly made it an attractive target. (Nod to > the past week's releases by the Shadow Brokers, which are > surely the tip of the tip of the iceberg.) > > Nobody with poor email habits, e.g., top-posters, > full-quoters, people who use HTML markup. (Since these undercut > encryption, sometimes rather badly.) > > Nobody using the IOT to send or receive email, e.g., their > car, which was very likely pre-compromised at the factory. > > That doesn't leave a lot of people. This analysis doesn't correspond at all to the real-life use case that I'm familiar with, of an encrypted mailing list that we're using quite successfully. We're not using it with the intention of creating an illusion of the traffic of that mailing list thereby achieving a high degree of protection of confidentiality. We're quite aware that that is not the case. In fact, everyone is aware of how easy it is to get onto that mailing list, a process that does not involve any serious vetting besides (due to the encrypted nature of the list) the fact that prospective subscribers are required to provide an OpenPGP public key. It's almost an open list, with a correspondingly low expectation of confidentiality. More confidential exchanges are always by off-list encrypted email. The encrypted mailing list nevertheless plays a very significant role in allowing those off-list encrypted email conversations to happen, by ensuring that all participants in the overall group continually have the capability of sending and reading encrypted email, and by providing a well-defined way for obtaining the public keys of any participants of the overall group (we can obtain them from the mailing list server). > I'm not saying "don't do it". As an intellectual exercise and a > development challenge, it's interesting. I'm saying "make sure -- > if people are thinking about deploying this -- that they understand > that they have almost no chance of making this work as intended > in the real world." As far as I am able to tell, the encrypted list that I mentioned is working as intended for us. I do however agree with rsk's analysis in so far as I agree that his arguments show that if one's intention with an encrypted mailing list were to thereby make the communications of just about any large group of people in some sense very secure, that would be an unrealistic intention, for which there'd be almost no chance of making it work in the real world. Greetings, Norbert From turnbull.stephen.fw at u.tsukuba.ac.jp Wed Apr 19 01:47:02 2017 From: turnbull.stephen.fw at u.tsukuba.ac.jp (Stephen J. Turnbull) Date: Wed, 19 Apr 2017 14:47:02 +0900 Subject: [Mailman-Developers] Encrypted lists predictable difficulties and implementation needs In-Reply-To: <20170417232252.GA20725@gsp.org> References: <78383d49-08a8-320a-27d7-cc573cbd28da@forestfield.org> <20170316014746.GA19047@gsp.org> <20836e20-3a1f-57bc-d520-8fa722b3fbc0@forestfield.org> <20170316144626.GC31856@gsp.org> <20170316201003.3dfa529d@quill> <20170318175405.GA32096@gsp.org> <20170319181422.5febb8d9@quill> <20170417232252.GA20725@gsp.org> Message-ID: <22774.63958.407840.480080@turnbull.sk.tsukuba.ac.jp> After I wrote most of this, I see Norbert covered some of the same points, but from the point of view of his specific use case. So I'm just going to send despite a bit of redundancy. Rich Kulawiec writes: > Granted, this will diminish as more communications become encrypted, but > for the forseeable future, anyone using encryption or similar privacy > measures will be targeted: > > https://www.wired.com/2014/07/nsa-targets-users-of-privacy-services/ The people I know (and I don't know any so it's no use trying to figure out who they are :-/ ) who develop encrypted communication systems seem to disagree with you about the use cases for this: they do use encrypted mail. I think about it this way: as you will undoubtedly point out, they know they're targeted, and they have the skills and motivation (see "know they're targeted") to do something about endpoint security. So given that their perceived threats aren't in the endpoints, they apparently see encrypted channels as useful. In many of the use cases that have been discussed in the past, we are looking at lists where the users have *specific* threats they're worried about, such as (ex-)spouses and other stalkers, employers, and public insecure wireless (since it's a mailing list, you need to worry about whether your correspondents -- whose identities you may not know -- are all using VPNs etc). While I agree with your assessment of "a billion pwned devices on the Internet of Threats[tm]", I don't necessarily think that any given user's threat is going to be a relevant pwner. (And in fact we already know that they compete with each other, and I see no reason for that to change. Sure, the FSB and NSA will be the biggest players, but they also have some incentive not to advertise openly even on the "dark web".) Yes, users need to be aware of the issue that their personal endpoint is not that hard to hack, and that if that happens it's not the ML's fault that their enemy is reading their "secure" mailing list posts. They also need to be aware that *anybody* subscribing is a passive threat (by "passive" I mean that if that person's endpoint is hacked, who knows who might have access to cleartext). For that reason I am of the opinion that encrypted mailing lists should be anonymous by default. > So if it becomes desirable or profitable for the new owners of > those systems to pay specific attention to encrypted mailing list > traffic, they will...and probably much quicker than anyone > anticipates. I'm not going to anticipate how long it will take, I'm going to assume that encrypted traffic will attract attention, including attempts to crack it just for the lulz, from the get-go. But I suspect that the really skilled and dangerous folks won't bother targeting encrypted traffic. They'll just read everything anyway, maybe sift through it with text mining tools. I suppose such tools might be instructed to check for encrypted traffic just to save cycles by not grepping the encrypted parts, and that could lead to lists of encrypting endpoints and specific targeting as you suggest. > Thus the target end user population for encrypted mailing lists > looks something like this: You're clearly assuming we all count APT28 among our enemies. I don't think so! Yes, I assume that if a "private sector Echelon" indeed comes into being there will be a market for its services and any previously collected information it preserves. I'm not sure garden-variety snakes in the grass will be able to afford it, though, and of course it will be a "dark web" thing, so hazardous to the health of would-be users. In other words, I agree to an extent with Norbert that this *will* increase the cost of targeting list traffic and provide a certain amount of "political" deterrent (in the sense of being on the dark web). > I'm not saying "don't do it". As an intellectual exercise and a > development challenge, it's interesting. In other words, it should be a GSoC project. It is, or at least we're hoping it will be. :-) > I'm saying "make sure -- if people are thinking about deploying > this -- that they understand that they have almost no chance of > making this work as intended in the real world." Yeah, well, good luck on that. 62 million Trump voters will believe whatever the Breitbart review says. :-( Steve