So this basically means within an enterprise instance of Slack -- "your" messages can be decrypted and made available for consumption if required?
[deleted]
Slack enables customers to control their encryption keys in enterprise version
161–170 of 178 posts
Re: Slack enables customers to control their encryption keys in enterprise version
#162Just to be clear, does it say anywhere that Slack does/doesn't retain access to the key store? It seems like it would be impossible for the service to work without maintaining access to the keys from their servers, so nobody should expect this to provide end-to-end privacy. Is that correct?
The key store lives in the customer's AWS account, and they can revoke keys or complete access at any point.
Re: Slack enables customers to control their encryption keys in enterprise version
#163I am not sure slack can ever meaningfully become encrypted while having persistence. All it takes is for a admin (or hacked admin account) to change the password of the target slack user and login as said user to view all their private messages. The encryption is mostly pointless as far as I can tell when all of it is circumvented by a changed password.
Depends on what you mean by "meaningfully encrypted". If E2E encryption is what you are going for, then yes. Companies that use Slack specifically don't want that, though, since they want to be in control of all communications (due to industry regulations or whatever other reason). So it is still encrypted, but the company holds the keys.
Re: Slack enables customers to control their encryption keys in enterprise version
#164Earlier quoted context omitted.
You forget that this is supposed to protect the enterprises against hostile action by Slack itself. This, of course, it does not do, as slack could simply change the application to accept an additional key, or to just do what they want done without any request. I don't understand that about companies. The trust situation just doesn't change: Before "managing their own keys", they have to trust Slack to not break thei…
I would argue that your threat-model is wrong in this scenario. EKM isn't there to protect you from the company that you're using, it's to protect both you and the company from legal overreach. I work at a company that does EKM for its customers. It doesn't force us to secure our customers' accounts, it allows us to secure them. We get to say things like "I'm sorry, we are unable to pull this data" rather than having…
Then perhaps I suggest you search Microsoft Skype. Providers can be forced to modify code as well:
https://www.google.com/search?q=microsoft+skype+legal+interc...
Do you seriously doubt Microsoft was forced to include legal intercept in Skype after reading the first 3-5 links there ?
So I disagree with your assessment that it provides any protection whatsoever. Perhaps it raises the difficulty a bit.
Re: Slack enables customers to control their encryption keys in enterprise version
#165Earlier quoted context omitted.
I would argue that your threat-model is wrong in this scenario. EKM isn't there to protect you from the company that you're using, it's to protect both you and the company from legal overreach. I work at a company that does EKM for its customers. It doesn't force us to secure our customers' accounts, it allows us to secure them. We get to say things like "I'm sorry, we are unable to pull this data" rather than having…
Then perhaps I suggest you search Microsoft Skype. Providers can be forced to modify code as well: https://www.google.com/search?q=microsoft+skype+legal+interc... Do you seriously doubt Microsoft was forced to include legal intercept in Skype after reading the first 3-5 links there ? So I disagree with your assessment that it provides any protection whatsoever. Perhaps it raises the difficulty a bit.
It is a perfectly sensible threat model to exclude government intervention. Perhaps more sensible, on the grounds that the government can always make your life hard in other ways, and the government can get away with not following the law. There are lots of meaningful attackers who are unaffiliated with the government, and it's absolutely worth protecting against them.
Re: Slack enables customers to control their encryption keys in enterprise version
#166Earlier quoted context omitted.
If they implemented one of the first two front-ends I linked, you would know what the message was and would not have to ask your friends to repeat The only people that opt-in are the IRC server infrastructure engineers. End users just connect to the web front end. The first two links turn your IRC servers into a Slack clone, except with more or less features. This is certainly non-trivial to set up and maintain and e…
Now I don't understand. I'm clearly talking about other people (everyone else but you), not the nerd running irssi on a VPS nor thelounge. In other words, IRC isn't worse than Slack/Discord in this regard because you have to opt-in to these things. It's worse because everyone else has to, and they clearly don't. For example, that I pay $50 to irccloud but nobody else does still makes IRC a poor experience for me beca…
I am not talking about putting TheLounge or Convos on a VPS node. I am talking about IRC administrators putting that, or a fork of that in front of their IRC infrastructure, so that you and your friends will have chat history / session persistence.
The reference to VPS nodes was specifically for the case of WeeChat or Epic in a tmux or screen session as yet another alternate option. That is in no way related to TheLounge or Convos.
Re: Slack enables customers to control their encryption keys in enterprise version
#167Earlier quoted context omitted.
Now I don't understand. I'm clearly talking about other people (everyone else but you), not the nerd running irssi on a VPS nor thelounge. In other words, IRC isn't worse than Slack/Discord in this regard because you have to opt-in to these things. It's worse because everyone else has to, and they clearly don't. For example, that I pay $50 to irccloud but nobody else does still makes IRC a poor experience for me beca…
I am not talking about putting TheLounge or Convos on a VPS node. I am talking about IRC administrators putting that, or a fork of that in front of their IRC infrastructure, so that you and your friends will have chat history / session persistence. The reference to VPS nodes was specifically for the case of WeeChat or Epic in a tmux or screen session as yet another alternate option. That is in no way related to TheLo…
> I am talking about IRC administrators putting that, or a fork of that in front of their IRC infrastructure
...at which point you're just reinventing Slack, except you're depending on random volunteers to pay for and manage the infrastructure of it.
Re: Slack enables customers to control their encryption keys in enterprise version
#168Earlier quoted context omitted.
Why do you believe employees are worried about the actions of Slack instead of the actions of their own employer? This change allows companies to spy on employees.
No it doesn't! Employers have been able to read messages on Slack for ages now.
Oh, whoops. I guess they caved to pressure.
Re: Slack enables customers to control their encryption keys in enterprise version
#169Earlier quoted context omitted.
Then perhaps I suggest you search Microsoft Skype. Providers can be forced to modify code as well: https://www.google.com/search?q=microsoft+skype+legal+interc... Do you seriously doubt Microsoft was forced to include legal intercept in Skype after reading the first 3-5 links there ? So I disagree with your assessment that it provides any protection whatsoever. Perhaps it raises the difficulty a bit.
It is a perfectly sensible threat model to exclude government intervention. Perhaps more sensible, on the grounds that the government can always make your life hard in other ways, and the government can get away with not following the law. There are lots of meaningful attackers who are unaffiliated with the government, and it's absolutely worth protecting against them.
This does not result in a change of threat model at all. That's what I've been pointing out. It does not protect against anyone at all, nor does it make you more vulnerable to them.
It does not exclude government intervention at all. The government still has the power to compel a change in the code that works with the encryption keys. When that happens, exclusive access to the keys, to put it mildly, won't matter.
If you think differently, let's see you put your actual trust in this process. You keep access to all your encryption keys and passwords, I even promise not to copy them, but you log into your web banking using a web browser I control. Which is the equivalent of the situation discussed here: I control the code interpreting the encryption keys, you control the encryption keys. Depending on your bank's authentication method I may or may not be able to copy the keys, but either way I'll be able to, say, change a bank transfer you make to my liking, which is really the point anyway. So I will transfer a suitable fee for your education, let's say $100, "without access to" your encryption keys to some charity of my choosing. Deal ?
Re: Slack enables customers to control their encryption keys in enterprise version
#170This is a good thing for computing freedom: it puts more control in the hands of customers instead of requiring them to outsource encryption to Slack. It's a small step, since it's Amazon KMS and since presumably Slack still sees cleartext in transit. But it goes in the direction of restoring the security profile that a customer did when they ran their own internal IRC server, and that's a good thing.
One day people will realize that control over encryption keys means nothing if you don't have control over the application using those encryption keys.
[deleted]