Re: [Mailman-Developers] Proposed: remove address-obfuscation code from Mailman 3
On Wed, Aug 26, 2009 at 10:57:06AM +0100, Ian Eiloart wrote: There's recently published research which suggests that simple obfuscation can be effective. Concealment, presumably, is more effective. At http://www.ceas.cc/ you can download Spamology: A Study of Spam Origins http://www.ceas.cc/papers-2009/ceas2009-paper-18.pdf I'm composing a combined reply to all of the comments here, but wish to reply to this single point separately. This paper seems well-intentioned, but has some very serious problems -- any one of which is sufficient to dismiss its conclusions entirely. Let me just enumerate a few of them; I'll spare you the entire list. 1. The authors presume that they can tell that an address has been harvested *and* added to at least one spammer database (or not) by observing spam sent to it. But that's wrong: we know that many addresses are harvested and never spammed, or not spammed for a very long time (as in years). Conversely, many addresses are spammed that have *never* been harvested. And some addresses that are harvested are spammed, but not because they were harvested. [1] And some addresses are picked up by routine/ordinary web crawlers, and then subsequently spammed, but not by the people running those crawlers. [2] This invalidates their measurement technique. 2. There's a major methodology error here: We began by registering a dedicated domain for this project, which we hosted on servers in our department. We know that some spammers -- the competent ones, who are the ones that matter -- use suppression lists based not just on domains, but TLDs, IP addresses, network allocations, ASNs, NS records, MX records, etc. We further know that anything tracing to a .edu or a network allocation/ASN associated with a .edu is quite likely to appear on those suppression lists. (This is an old tradition among spammers. Not all of them follow it, but quite a few do.) This also invalidates their measurement technique. 3. Statistics from any single domain are often wildly skewed one way or another. For example: I happen to host three domains which have the same name, but in three different TLDs. Everything else about them is exactly the same: NS, MX, web content, valid email addresses, etc. The spam they receive varies over three orders of magnitude. 4. And then there's this: it doesn't cover use of the single largest current vector for address harvesting -- zombied systems. No discussion of contemporary address harvesting techniques can even be begun without considering this. It's like writing a paper on tides without factoring in the moon's gravitation. [3] (I checked to see if perhaps this paper's publication predated the rise of the zombies earlier this decade, but it's from 2009.) To put it another way: yes, there are still address harvesters using the techniques that these researchers were looking for. But these harvesters are outdated and unimportant; they're only used by spammers who don't have the expertise and resources to do better. And not only is that class of spammer is steadily shrinking, that's NOT the class of spammer we need to worry about, as it's quite easy to block just about all their traffic whether they have valid addresses or not. (C'mon, these are people who can't decode rskATgsp.org, do you really think they constitute a serious threat?) So like I said above, I'll spare you points 5-N, but they're similar. None of what I've said here is new or novel: it's common knowledge among experienced people working in the field. I think perhaps in the future that people trying to conduct this kind of research should spend a few years reading spam-l and other similar lists before diving in. The bottom line is that (a) the numbers they've produced have no meaning and (b) their conclusions are all wrong. Notes: [1] As an example: conside j...@example.com, and let's suppose that it's been deliberately exposed to one method of harvesting because it's published at http://www.example.com. If spam arrives, then it may be because the address was harvested by a web crawler and added to a spammer database -- or it may be because joe is very common LHS string and thus one that spammers are very likely to try in *any* domain. Note that while spammers' list of such likely LHS were quite limited years ago, they're not any more: spammers now have the resources to try all known and all plausible LHS strings if they wish. And they are: check your logs. You may be surprised at which LHS strings are being tried: what was computationally infeasible a decade ago is now routine. [2] It's not difficult to figure out who's running a web crawler: just setting up a web site, making sure it's linked to, waiting, and then analyzing logs will reveal a candidate list. It's somewhat more work to figure out which of those crawler operations can be broken into, but it has significant advantages: it allows one to mine all their data without the expense/hassle of
Re: [Mailman-Developers] Proposed: remove address-obfuscation code from Mailman 3
On Tue, Aug 25, 2009 at 06:39:29AM -0400, Barry Warsaw wrote: So you can explain why, in theory and in practice, obfuscation doesn't work. But the user base will (stubbornly, if you like) refuse to accept your logic. As usual, Stephen hits the nail on the head. I can't disagree with much in Rich's post, and yet it's likely that we'll still obfuscate and/or conceal email addresses in the archives because users will demand it. You can and should educate them, but this is not a battle I wish to fight because I think we can't win it. I've thought this over for quite some time (obviously), and have done some homework elsewhere to ascertain whether both Stephen's and your (Barry's) comments are accurate. They are. Very much so. There now exists a cargo cult mentality which insists that obfuscation has some anti-spam/security value, in spite of overwhelming evidence and experience that conclusively proves it has none whatsoever. (As an aside, not to either of you but in response to other comments in the thread, I'm well aware of the concept of defense-in-depth and practiced it years before the term became common. But for any measure to be part of defense-in-depth, it must first qualify as a defense, albeit perhaps a weak or half-hearted one. Address obfuscation obviously fails to clear this bar, even as low as it's set.) I don't know how to dispell this widely-shared delusion. It may not be possible, at least in the near future. And it's probably not the role of Mailman's (or any other software package's) developers to tackle this issue; there's only so much policy that can be promulgated by code. I think perhaps the best that can be done is to insert a statement in Mailman's documentation indicating that this measure is provided for people who want to use it, but that it really has zero value. Whether or not y'all want to do that is of course up to you, but I think at least a nod to reality in the documentation might get some of the better mail system admins to at least start thinking about the issue. And maybe that's the best that can be done for now. ---Rsk ___ 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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] spammers harvesting email'ids [was] UI for Mailman 3.0 update
On Mon, Jun 07, 2010 at 02:28:22PM -0400, Barry Warsaw wrote: We can try to make it more difficult to harvest email address from mailing list archives and posts, but some of that is fairly difficult without disrupting the usability of the mailing list. Agreed, and as I pointed out last year, it's useless. Spammers have such an embarrassment of riches when it comes to harvesting addresses that they really don't need to bother with mailing list mechanisms. And since I wrote that lengthy explanation, they've come up with a few more, including one that's really quite clever since it uses social engineering to convince users to give up not just addresses, but information on the relationships between them. So there is not only zero value in trying to obfuscate addresses, there is *negative* value since the only people who will actually be impaired in the least by this are those actually trying to communicate, e.g., those coming across a message in an archive and trying to write to the author. Spammers are already so far past this that it's disappeared from their rear view mirrors. ---Rsk ___ 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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] UI for Mailman 3.0 update
On Sun, Jun 06, 2010 at 04:29:14PM -0400, Crist?bal Palmer wrote: The ability to use reCAPTCHA or other CAPTCHA systems as part of the web signup would also significantly reduce spammy signups, so if we could have MM3 ship with a CAPTCHA system and/or support for a class of CAPTCHA systems in the default web UI, that would be super. No, it won't. Spammers have quite thoroughly defeated these, years ago, via an assortment of techniques. Yes, some deployments don't see this: they're not considered important enough to attack. But as Yahoo most recently found (and they're only the most recent entry in a long parade) when spammers or other abusers decide it's time, they can rapidly solve them by the tens of thousands. Moreover, there's really no need for spammers to trouble themselves with this approach. If the goal is address-harvesting, then there are far more efficient ways that yield much better results. If the goal is to spam the list, then it's much easier to hijack an already-subscribed account -- particularly if it's located at one of the many freemail providers whose security is weak, but alternatively by via the subscriber's own system. There does not exist a truly effective defense against these attack vectors for lists of substantial size. (Very small lists can be defended by limiting membership, mail account location and operating system but these are clearly special cases and these tactics don't scale.) This isn't surprising, nor is it Mailman's fault: when the adversary owns so much infrastructure, it's just not going to be possible to craft defenses that work other than temporarily and accidentally. One mitigation step -- and it's not a terribly good one, but at least it's one with minimal impact -- is to employ the policy that list subscribers posting from freemail providers are always moderated. Of course this only intercepts one vector and of course it requires manual intervention -- which is why I *said* it's not terribly good. But experiments I've run indicate that at least for the moment, it deals with the most likely attack vector, and it has the virtue of using an existing mechanism. But, captchas? Pre-defeated. ---Rsk ___ 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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Gitlab integration, GSOC'16
On Mon, Feb 29, 2016 at 05:41:27AM -0800, Terri Oda wrote: > The tweet linked talks about moving a discussion from a mailing list > to a bug tracker. An easy way to do that (while leaving the mailing list discussion intact and not requiring that people have accounts on the bug tracking site in order to participate) is to link to the archive of the discussion -- specifically, to the message which begins the discussion thread. This has the useful feature that as new followups arrive (and the discussion continues) the link doesn't need to be updated. (Well, provided that everyone participating in the discussion uses a mail client that correctly manipulates headers in replies.) I've done quite a bit of this with internal debug/development lists and have found that users catch onto it quickly. (Oh, and one small augmentation: sometimes it can be useful to have a process in place wherein the person who commits the feature or bugfix is responsible for saying so in the discussion thread. This creates a very useful history with a lot of context that can be highly valuable to future archaeology efforts.) ---rsk ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] CAPTCHA support
On Sat, Mar 05, 2016 at 04:27:31PM +0530, Aditya Divekar wrote: > I was looking around the mailman code, and could not find the functionality > for captcha in the mailing lists subscription pages. As someone who has been studying email abuse for 30+ years, I strongly recommend against captchas for several reasons. First, as noted elsewhere in this thread, they're problematic for impaired or disabled users. Second, they've been quite thoroughly defeated by advances in image processing and character recognition. We have long since passed the point where the difficulty of captchas solvable by software has exceeded the difficulty of captchas solvable by humans. Third, as often noted elsewhere, it is relatively easy to conscript humans (knowingly or unknowingly) into the mass solving of captchas. Fourth, either a given instance is or is not a target of interest to adversaries. If it is not, the captchas are of course not needed. If it is, then they will not help: any modestly-clueful adversary will go through them like they're not even there. Bottom line: captchas are, at best, wishful thinking. There is zero operational reason to deploy them in 2016. ---rsk ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Encrypted lists predictable difficulties and implementation needs
On Wed, Mar 15, 2017 at 11:31:44PM -0500, J.B. Nicholson wrote: > I understand there are more insecure devices on the Internet all the time > and that's unfortunate, but I don't think it's avoidable. What do you > suggest we do about this using Mailman (since this is Mailman-developers)? I suggest that Mailman do nothing, because even if it solves all the problems that it can solve, all it will do is provide a thin veneer of security/privacy on top of a thoroughly rotten foundation. Yes, there will be small, limited cases where it'll be able to deliver on its promises -- because every person involved is diligent and every device involved is secure -- but that's clearly not the way to bet. Moreover, none of this comes for free: there is opportunity cost, complexity cost, maintenance cost, interoperability cost, etc. In my view, it's not worth incurring all these costs to implement something that we already know, today, right now, is not going to work in the contemporary Internet environment -- because it relies on underlying assumptions about endpoint security that almost certainly won't be true as soon as the deployment scale reaches modest numbers. I think a better course of action is to recommend that those with the sort of requirements being articulated here not use mailing lists at all. ---rsk ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Encrypted lists predictable difficulties and implementation needs
On Fri, Mar 17, 2017 at 09:54:48AM +1100, Morgan Reed wrote: > I'd submit that this is tantamount to saying "it's impossible to make a > 100% secure system so why bother even trying". Then you're not grasping my point. Let me try again. I suggest that you re-read what I've written *and* consider as well the disclosures of the past week vis-a-vis smartphones and their encrypted communications applications. In particular, note that entities like Whisper and Signal have been, as I've said for years, peddling snake-oil. They cannot possibly deliver on their promises *even if they do everything they say they can do* because all of it is immediately and completely undercut if the underlying system is compromised. Which is exactly what the disclosures of Vault 7 show everyone, although it's not really news to anyone who's been paying attention. Intelligence agencies, vulnerability brokers, organized cybercrime, and others have been knocking themselves out to hack everything for years -- and whaddaya know, they've succeeded. This set of disclosures is merely the latest, and it and all the other ones to date are merely the tip of the iceberg. So what I am saying, and what I hope is obvious, is that you cannot build a secure system on top of an insecure one. This isn't about not being able to build a 100% secure system: as a long-time security professional, I'm fully aware that's impossible and that the best we can do is to stack the deck in our favor. This is about building a system that is known 0% secure from the start. I think, in the end, this will serve the community poorly -- because people who don't grasp the contemporary security landscape will deploy it, will rely on it, and will not understand that they lost the game before they even started to play it. This will have consequences. ---rsk ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Encrypted lists predictable difficulties and implementation needs
On Thu, Mar 16, 2017 at 08:10:03PM +0100, Norbert Bollow wrote: > Even if not every device is secure, the difficulty, and likely cost, > for an attacker to snoop on the communications is much greater for an > encrypted mailing list is than for a non-encrypted one. The difficulty is greater -- but not by much. Attackers have long since become extremely proficient at installing keystroke loggers and extracting credentials in order to compromise many other forms of communication. It's only an incremental, low-cost step for them to extend those techniques to encrypted mailing lists. Now I'll grant that this is unlikely to happen immediately (except for intelligence agencies, who will be ready for this before it's deployed in the field). But one of the things that we've seen over and over again is that once attackers decide that a particular target (or kind of target) has value, they'll focus on it with surprisingly rapidity. ---rsk ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Encrypted lists predictable difficulties and implementation needs
On Thu, Mar 16, 2017 at 05:30:36PM -0400, Barry Warsaw wrote: > On Mar 15, 2017, at 09:47 PM, Rich Kulawiec wrote: > > >What all of this means is that once a list passes N members, where > >we can debate about N, the probability that at least one of those > >members has already been compromised even before they've joined the > >list starts rapidly increasing. > > That assumes an open membership policy. Wouldn't much of this be mitigated > with a closed subscription policy? It *might* be. The problem is that the list owner and other list members have no way to know. From their point of view, there is no way to know that whether the latest list member -- whether that's list member #8 or #7,221 -- is using a reasonably secure mail client on a reasonably secure operating system in a reasonably secure environment -- or whether they're reading list traffic on an iPhone that was fully compromised eight months ago. Morever, even if that newest list member is doing the former today, nothing from prevents them from doing the latter tomorrow. (Yes, one could ask them not to, even make not doing so a condition of membership. That won't work. Somebody is going read email on their fridge or their car or their Android phone because they can, because they're lazy, because it's convenient, because they feel like it.) It's thus impossible to (a) estimate the risk or (b) control the risk or (c) know when a full compromise has taken place, absent outside indicators. That's a really bad combination to have in anything that's trying to be secure. > Yet there still may be value in encrypting the communication channels > into and out of Mailman, even if that can be compromised at the end-points. I agree. > >I can sadly report that the problem is getting worse and will continue > >to get worse, because (a) all of the various factors contributing to it > >are also getting worse and (b) there are no reasons for anyone to > >significantly invest in making it better. > > (b) is not necessarily true. There is lots of work going on to provide secure > base platforms on which to implement IoT devices. I'm aware of at least some of that, and I'd like to hope for the best. But economic incentives being what they are, there is little motivation for vendors to bother. Moreover, many vendors are deliberately compromising end-user privacy and security (e.g., Vizio) because it's profitable to do so and the penalties, if any, are a mere slap-on-the-wrist. (I know you see a lot of this because of what you do; other folks might want to browse through TechDirt's ongoing partial catalog of IoT failures.) My view -- at the moment, ask again tomorrow ;) -- is that so many IoT devices have been rushed to market with no consideration for security and privacy issues that the present situation is untenable. The best thing would be to recall *all* of them: all the smartphones, all the watches, all the TVs, everything...and start over. That's of course ludicrous and won't happen. Which means all those devices will persist in the field, joined by new ones in large numbers every day. And the slow backfill of fixes which *might*, in a vacuum, actually suffice, aren't going to be enough because so much of the rest of the IoT ecosystem is a mess. In a relatively short time we've taken a system built to resist destruction by nuclear weapons and made it vulnerable to toasters. --- Jeff Jarmoc ---rsk ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Encrypted lists predictable difficulties and implementation needs
All of these proposals overlook significant known, current threats -- none of which they're capable of addressing, but some of which badly undercut the suggested approaches. To list just one of those -- albeit a rather prominent one -- the Internet's population of hijacked systems (aka bots or zombies) continues to grow. This has been a growing problem for the last 15 years, e.g.: Vint Cerf: one quarter of all computers part of a botnet http://arstechnica.com/news.ars/post/20070125-8707.html I have studied this issue extensively since 2002 and while I initially thought Cerf's estimate a bit high, further study and retropection suggests that it was probably about right. Extrapolating to the present day, one-quarter is probably still about right -- but of course the system population has grown massively in the interim. The problem has recently been badly exacerbated by the rapid deployment of IoT devices whose security ranges between "laughable" and "non-existent". These in turn are quickly being utilized to compromise other systems. The problem is also being badly exacerbated by various governments and organized criminal operations which are developing, acquiring, and deploying zero-days as fast as they possibly can. And it's being further exacerbated by the increasingly sophisticated attacks conducted by less prominent and well-resourced adversaries; to put it another way, the average attacker now has access to means and methods far beyond what they had a decade ago. I rather suspect that "one quarter" will become "one third" in the next few years. What all of this means is that once a list passes N members, where we can debate about N, the probability that at least one of those members has already been compromised even before they've joined the list starts rapidly increasing. Of course other factors may mitigate this: if all N members use exclusively open-source software, do not use freemail providers, do not use smartphones or IoT devices, etc., then the probability that one of them is compromised diminishes. (Worth noting that in a list constituted like this, encryption offers little additional security value, since its members are already doing the things most likely to avoid being compromised.) If on the other hand, some of the list members are using worst practices, then the probability that at least one is compromised will increase. As I said, we can debate N -- and we can debate the probability. What is not open to debate is that this is real and significant. Very long experience running mailing lists and observing partial bot-generated activity from members strongly suggests, to give just one data point, that once N reaches "a few hundred" the probability approaches unity. However, I must emphasize that the word "partial" means that this is a significant UNDER-observation -- it's very clear that there is bot-generated activity I'm missing. Rather a lot of it, actually. So "a few hundred" is probably a highly optimistic estimate for N and its true value is probably much lower. So even if the encryption works perfectly (which it won't) and it's deployed perfectly (which it won't be) and it's usable by everyone (which it won't be) and it plays nice with policies like attachment removal, signature removal, boilerplate addition, etc. (which it won't) and the encryption algorithm is perfect (which it won't be) and the encryption implementation is perfect (which it won't be) and all of this rather complex machinery works perfectly...it will all be rendered moot the moment one list member's system is compromised. In other words, what you propose to build here is an extremely brittle system that's subject to total failure if even just a single endpoint fails. And there are *hundreds of millions* of endpoints that have already failed. Thus, even assuming that the systems of encrypted-list members aren't specifically targeted, there is an uncomfortably high probability that the messages traversing it will be pre-compromised from the start. And of course if those systems *are* specifically targeted, which of course is likely for people with use cases that suggest encrypted mailing lists, then the threat models changes and no longer consists of the normal level of attacks that all systems are subject to, but includes an elevated level of attacks that will target them in particular. I think that this is an instance where a huge amount of well-intended design and development effort will result in a "solution" that cannot provide what it intends to because underlying circumstances prevent it. And -- having studied those underlying circumstances for a long time -- I can sadly report that the problem is getting worse and will continue to get worse, because (a) all of the various factors contributing to it are also getting worse and (b) there are no reasons for anyone to significantly invest in making it better. ---rsk ___
Re: [Mailman-Developers] Encrypted lists predictable difficulties and implementation needs
On Tue, Mar 21, 2017 at 04:04:20PM +0100, johny wrote: > Shifting the attacker to actively compromise devices is an overall > improvement. If "compromising devices" was difficult, I might agree. But it's not. Devices of all descriptions have been and are being compromised in enormous numbers on an ongoing basis even by relatively unskilled attackers -- since they can buy/lease the requisite tools and infrastructure and use them without needing to understand how they work. I think you (and others) are continuing to badly underestimate the scale at which this is taking place. We're not talking about an ecosystem in which 2% or 6% of devices are compromised; we're talking about one in which any estimate under 25% should be laughed out of the room and an estimate of 50% should be given serious consideration. (I think the latter may be still be too high. But it's certainly within the realm of plausibility.) We're also talking about an ecosystem in which, increasingly, vendors are shipping devices that are essentially pre-compromised at the factory due to very poor and entirely self-serving design and implementation decisions. > There are plenty of threat actors for which sniffing traffic to a > plaintext mailing list might be easy, however overcoming a well setup > encrypted mailing list system would be quite hard. I don't think so, if the mailing list is of sufficient size. (Certainly one with only a handful of people might be hard to crack, but that would be fairly hard today even without encryption.) > The system security only increases in this case. It's security is > obviously debatable against state actors/equivalent threats, there it > might not improve much, but improves significantly against other threats. State actors are not necessarily the biggest threat. They might have the most resources, and they might have the best cryptographers, and they certainly have the most political power (e.g., NSLs in the US), but they also have their own areas of focus and this may not be one of them. If there's money to be made by trafficking in information, then others will take an interest. They may not have the resources, cryptographers, power, etc., but they do have some very talented personnel, stockpiled exploits, and rather a lot of experience with mass compromise of end user systems. These are not script kiddies in mom's basement, these are professionals with the discipline to identify and attack targets successfully on a large scale. Don't underestimate them. *That* particular mistake was already made by every ISP on this planet ~15 years ago, which is one of the major reasons the problem has the scope that it has today. ---rsk ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Encrypted lists predictable difficulties and implementation needs
On Sun, Mar 19, 2017 at 07:33:24AM -0400, Richard Damon wrote: > I would say that the problem that is being attempted to solve is > fundamentally impossible to do perfectly. It is impossible to distribute > messages in a secure manner to a number of recipients that you don't have > total control over their enviroment and KNOW that security is being > maintained. Communication always has that sort of issue, if you tell someone > something private, you need to be able to trust that they will keep it > private, and their is always a risk that they will reveal the information > intentionally or accidentally. [snip] I think this (and the rest, which I've elided for brevity) is a very good statement of the problem. I'll just add that -- in the general case, and quoting from the above, we already KNOW that security is *not* being maintained. It's not an open question, it's been answered very clearly for well over a decade. (In the specific case, e.g., the right people using the right devices with the right knowledge and self-discipline: maybe. But there are not many of those cases and any of them can revert to the general case in seconds with one poor decision or perhaps even without one.) ---rsk ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Encrypted lists predictable difficulties and implementation needs
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 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 ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
