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
On 03/18/2017 09:04 PM, Rich Kulawiec wrote:
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.
Open Whisper Systems and Signal provide what they state, End-to-End encryption. Applications and technologies like these make mass surveillance harder, as passively sniffing traffic is no longer viable. Shifting the attacker to actively compromise devices is an overall improvement.
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.
Obviously protection against state actors is hard 1. However thats not the only threat source that there are reasons to protect against. 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.
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.
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.
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.
This assumes that those people are not currently relying on plaintext mailing lists or any other insecure messaging technology. I think it is quite obvious, from the nature of a mailing list, that every subscriber can read all messages. With proper documentation about security of endpoint devices and security of mailing lists, I think this feature has viable use-cases.
-Jan
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
On 03/21/2017 11:16 PM, Rich Kulawiec wrote:
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.
Before introducing encryption during transport an attacker had a choice to either sniff traffic or compromise a device. Plugging one hole, encrypting the transport, *MUST* be an overall security improvement, it will not be only in some edge circumstances.
I think that the percentages you are presenting are not the right ones for what you could expect from users of a GPG encrypted mailing list. a) The fact that they are even considering to subscribe to an encrypted mailing list, that they have a GPG keypair moves the probability that they are doing this on a compromised device way lower. (at least I think so, I don't have any concrete data) b) You are assuming that the percentages you give are actually all one homogenic attacker, aimed at gaining access to an encrypted mailing list, having the capabilities to do so and having control of X% of devices. No such one attacker actually exists.
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.
I still think that there is a security improvement that outweights the drawbacks. Of which two were noted:
a) Mailman's encrypted mailing list security will be over-estimated by naive users that will get bitten by this. This is valid for cases where the users aren't already communicating in an insecure way (which is likely), so only covers a small userbase and can be tried to be mitigated by proper warnings, documentation, common sense. (As many E2E and similar apps do, or should do, warn that endpoint security is important and that endpoint compromise is catastrophic)
b) Added complexity, maintenance cost to Mailman's infrastructure. This can be mitigated by implementing encrypted mailing lists either as a plugin as was proposed here before, or just by making the feature as non-intrusive into Mailman's infrastructure as possible . (which I think is doable if the proposal aims to do so)
-Jan
Jan Jancar writes:
b) Added complexity, maintenance cost to Mailman's infrastructure. This can be mitigated by implementing encrypted mailing lists either as a plugin as was proposed here before,
In one sense, a plugin is the ONLY way this feature can be reasonably implemented in Mailman 3, as all the relevant work will be done in Rules and Handlers.
However, as Mailman core tends to provide information to companion applications (Postorius, HyperKitty) without much concern for authorization, there may be issues that require either invasive changes or can only be addressed in current Mailman 3 architecture by host security. The latter is the current answer to all questions of security, in fact.
This will indeed be an ongoing security concern in maintenance, unless the information that needs to be secured is by design carefully partitioned away from "low security" operations used by Postorius, HyperKitty, and the REST interface generally.
Steve
participants (4)
-
Jan Jancar -
johny
-
Rich Kulawiec -
Stephen J. Turnbull