Slack Doesn't Have End-to-End Encryption Because Your Boss Doesn't Want It (vice.com) 92
Business communications service Slack, which has more than three million paying customers, offers a bouquet of features that has made it popular (so popular that is worth as much as $9 billion), but it lacks a crucial feature that some of its rivals don't: end-to-end encryption. It's a feature that numerous users have asked Slack to add to the service. Citing a former employee of Slack and the company's chief information security officer, news outlet Motherboard reported Tuesday that the rationale behind not including end-to-end encryption is very simple: bosses around the world don't want it. From the report: Work communication service Slack has decided against the idea of having end-to-end encryption due to the priorities of its paying customers (rather than those who use a free version of the service.) Slack is not a traditional messaging program -- it's designed for businesses and workplaces that may want or need to read employee messages -- but the decision still highlights why some platforms may not want to jump into end-to-end encryption. End-to-end is increasingly popular as it can protect communications against from interception and surveillance. "It wasn't a priority for exec [executives], because it wasn't something paying customers cared about," a former Slack employee told Motherboard earlier this year.
Mattermost is an alternative (Score:5, Informative)
Mattermost [mattermost.org] is an open source, privately hostable clean room reimplementation of Slack that supports a variety of encryption options [mattermost.com] that Slack does not.
Re: (Score:3)
Re: (Score:3)
It's open core. Look into matrix.org / riot.im instead
Re: (Score:2)
Re: (Score:2)
So how does it handle legal ediscovery? Employers are responsible for coughing up employee communications during trial.
Maybe. I am not a lawyer, but the case of the governor and the disappearing text messages [thehill.com] seems relevant. Maybe, if the company never had access to the messages, it doesn't have a responsibility to reveal them.
Re: (Score:2)
I think the company only has to produce materials that they have at the time they are notified that legal action is coming. If the company sets an email retention policy of 30 days, then they aren't responsible for producing emails from 5 years ago, since those were deleted in the ordinary course of business. The same would likely apply to material that the company never had possession of in the first place, such as SMS messages sent between personal phones or email sent between person
It's good to know (Score:2)
Re: (Score:1)
Except it's not, because it is encrypted between the users and the slack server, it's only saying that the don't provide client to client encrypted tunnels for DMs, which is hardly the big deal that this article title makes it out to be.
Trivial to fix and keep secure -- use an ADK (Score:2, Interesting)
This is a trivial thing to fix for a business. Slack can always have all messages done as part of a certain company (both to and from) be encrypted with an additional decryption key (ADK).
PGP Desktop had this functionality since the early 2000s, allowing encryption, but allowing businesses to easily recover encrypted E-mails, but yet not subverting private key security with key escrow or other backdoors.
With all the people into blockchains and applied cryptography, it is amazing this wasn't done.
Just because your customers don't care about it (Score:5, Insightful)
doesn't mean they shouldn't, and not making it available creates a risk in situations where they suddenly discover they need it yesterday.
As a designer you frequently put things into a product that customers never asked for. Sometimes, yes, it is a waste of time. But if you don't bring expertise to the table the customers don't have, then what are they paying you for?
Re: (Score:3)
Re: (Score:3)
Exactly!
The Boss only really cares about what features they actively need for the money. Normally they will only care about it until after something happens that hurt them enough to change their thinking about it.
A massive Hack due to poor security will then change your bosses mind. However most cases of poor security go by without much consequences.
Strong Security is about having features in it that you hope you never need, but is there in case something happens.
Re: (Score:2)
doesn't mean they shouldn't, and not making it available creates a risk in situations where they suddenly discover they need it yesterday.
Yeah but that way you get to charge extra to put it in. A lot extra if they want it soon.
Re: (Score:2)
What is a possible scenario where their customers need end-to-end encryption right now.
And keep in mind that's end-to-end encryption. Not "encryption". Communications between the client and server are encrypted. The reason it isn't end-to-end is the server decrypts the messages before re-encrypting them for the recipient's collection.
Assuming your Slack server is running on a properly-configured host, that's compliant with things like HIPAA that "pop up out of nowhere".
Comment removed (Score:4, Insightful)
Re:hindsight is 20/20 (Score:5, Informative)
Alternatively, you could realize not having end-to-end encryption is not the same as not having encryption.
The client-server communications are encrypted. You just can't send a DM that the server can not read. At least, not directly through Slack.
Re: (Score:2)
Only if your requirements include DMs not being able to be read by the server.
Security-wise, end-to-end encryption would only protect against a very narrow set of attacks where the server is compromised, but not so compromised that it won't serve up a fake key as the recipient's key. I can't think of a realistic way to get into that state.
Re: (Score:2)
On the other hand, it lacking end-to-end encryption and having the server able to read everything in DMs certainly suggests a good route of attack, and it also would suggest that those running any given server cannot make a strong claim of not having a clue about the content of DMs. "We promised not to look and didn't" is a lot stronger when you can point out that you couldn't have looked anyway.
Sometimes, the point of security is not to protect against hackers but your own rear from having the legal syste
Re: (Score:2)
On the other hand, it lacking end-to-end encryption and having the server able to read everything in DMs certainly suggests a good route of attack, and it also would suggest that those running any given server cannot make a strong claim of not having a clue about the content of DMs. "We promised not to look and didn't" is a lot stronger when you can point out that you couldn't have looked anyway.
Except the context here is Slack running in a business. They aren't promising to not read your DMs, in fact they usually warn you they are reading your DMs.
If the context is a random person chatting with someone via DMs over a random server they find on the Internet, then Slack isn't your best choice....and never was.
End-to-end encryption would also harm the ability to scan messages for malware, which companies really, really love to do.
Sometimes, the point of security is not to protect against hackers but your own rear from having the legal system decide that having them in plaintext where you can see them means you should totally be reading it.
There's not going to be many situations where "we couldn't read the me
Re: (Score:2)
Sometimes, the point of security is not to protect against hackers but your own rear from having the legal system decide that having them in plaintext where you can see them means you should totally be reading it.
There's not going to be many situations where "we couldn't read the message" is going to excuse a company from liability. Let's say it's sexual harassment or similar interpersonal harm. The victim prints the DMs, takes them to HR who does nothing and there's a lawsuit. Monitoring the DMs would not have avoided the liability, since the problem comes from failing to deal with the harassment once it has been reported, not over detecting the harassment.
Not quite--the problem comes from failing to deal with the harassment once you are aware of it, last I checked. It would generally not be wise to wait for somebody to report it after you have, for example, had it happen rather publicly in front of a crowd that includes the head of HR. How much monitoring you're expected to do (vs waiting for somebody to report) will depend on local laws and judges.
If you're imagining some future law where businesses are supposed to magically find terrorists or similar, I really don't see any companies deciding not being able to read their employee's messages is better than a dumb keyword search that lets them pretend they're complying with the law with little to no effort.
Also, I also think you're vastly underestimating the stupidity involved to think a dumb keyword search on its
Re: (Score:2)
How much monitoring you're expected to do (vs waiting for somebody to report) will depend on local laws and judges.
[Citation Required]
You are rarely going to overestimate a politician's understanding of what computers can and cannot do
And because of that, they're not going to understand a keyword search is nearly useless. Nor even a far more sophisticated scan that theoretically determines context, since that is useless too.
By the way, that future law is in the process of being made in the EU.
Great! Point out in the draft legislation where something trivial like a keyword search wouldn't comply.....Oh wait! A keyword search is exactly what the EFF is worried about.
All run on Supermicro (Score:2)
Not to pick on a particular server vendor, but it must be assumed that the network is compromised, and that all communications will be recorded and analyzed by many unknown parties.
We got off telnet for a reason.
Can't they just share the keys with employers? (Score:3)
Re: (Score:3)
Two reasons:
1) Because then the breathless article would be talking about how the end-to-end encryption is "flawed".
2) The communications between the client and server are already encrypted. They're just decrypted on the server, re-encrypted for the recipient and sent on. End-to-end encryption with IT having a copy of your keys is functionally identical (assuming the server isn't compromised).
This makes no sense (Score:5, Insightful)
If I were Slack, I'd be much more worried about Microsoft Teams. Microsoft is pouring huge sums of money into Teams at the moment to make it the new paradigm and push for online, with the added benefit of tighter Office/O365 integration as well as integration of other pieces to make a unified communication solution. I get a bit concerned in that respect for market dominance by MS, but it is what it is.
Re:This makes no sense (Score:5, Informative)
It's not trivial, but I don't buy that unencrypted communications are the alternative for the reasons they state.
The client-server communications are encrypted. The reason it isn't end-to-end encryption is the server decrypts the messages before encrypting them for the recipient's connection and sending them on.
Basically, they do what you propose. But that isn't end-to-end because the server (aka "centalizing their archival") can read the contents of the messages.
Re: (Score:2)
End to end encryption means the server can not decrypt the messages. Only the recipient can. Think PGP-encrypted email body, where the recipient is the only one with the private key to decrypt the message. Any intervening servers can not read the message.
Skype encrypts the communication with the servers, but does not encrypt the messages. So the server can read the messages, but third parties can not (assuming the server has not been compromised).
That poster proposes a key-escrow-like system, which woul
Re: (Score:2)
s/Skype/Slack/
Re: (Score:1)
No, and most likely the thing we're not privy to is a government court order that says to not put it in, and explain it in whatever way you want.
Obviously, they would've put it in and at least added a switch for it if someone, as they claim, stubbornly refuses to use encryption.
This is why people should use Mattermost instead of Slack -- Slack is not secure, and it is wide open for government and other hacks.
Re: (Score:2)
End-to-end encryption must be open (Score:2)
You can't have end-to-end encryption with proprietary software. Even less so when it is done by a cloud service (a.k.a. man-in-the-middle).
Re: (Score:2)
You can setup SSH Port forwarding on the client.
That is the cheap, quick and dirty way secure systems, that cannot be encrypted by its poor design.
Re: (Score:2)
what nonsense, of course you can have end-to-end encryption with proprietary software and that's what the big enterprises use. you can have breakable encryption, weak encryption or no encryption with open source software too. where do you get your dumb wrong ideas?
Re: (Score:2)
the types of crypto that prioprietary devices use are listed and known. Are you imagining the aes-256-gcm in a palo firewall is different and inferior to the magic aes-256-gcm in an open source BSD?
We've already proven that auditible code can result in trusted insecure junk being used for decades.
shhhhhhhhh (Score:1)
Slack HATES IRC. They love fooling everyone into paying for a free 30 year old technology.
Slack would rather lie about IRC, or make idiotic excuses about encryption that are outright lies. The truth is, the Slack engineering team is so fucking stupid, they have no idea how to implement end to end encryption. Instead it's much easier for their inept engineering team to blame their lack of encryption on "my boss"
What a bunch of assholes of the highest order.
RocketChat has an OTR (Off The Record) mode (Score:1)
I've been playing with RocketChat for a while and it's a fairly decent Slack alternative that's under active development. If you want to go off the record in a private chat, click the button, wait for the other person to confirm, and your conversation is now end to end encrypted. It's fairly easy to install if you want to self host, and they offer hosted versions too. I'm a fan.
Simple Solution (Score:2)
Let the employer generate and keep a copy of the keys.
How you actually administer Bitlocker with employees on an enterprise network.
I Absolutely care, and I'm paying!!!! (Score:1)
I was never asked, and I pay for slack service for my startup team. I want secure comms that I can trust. We don't use slack for confidential strategy or product design calls. We use Signal. If I thought I could trust slack based on their design, we'd use it more. They just added 2 and 2 and got 17.
They Have To (Score:3)
It wouldn't be so bad if the company can generate and keep the keys, but other than that encrypted employee communication is a worse risk than potential loss of IP. The management and company is held responsible for for all sorts of "nanny" issues in the workplace, including any kind of alleged harassment, threat, insult, discrimination, etc. Without hard records of who said what to whom, the company is at much bigger risk from lawsuits from their own employees than from competitors stealing tech. It is management's job to police internal communication as much or more than to actually run the company; and trust me, most of us don't like doing it, but it is a legal requirement that we do, and a huge economic risk if we don't.
Wrong way around (Score:3)
I think you mean my boss doesn't want slack because it doesn't have end to end encryption... We recently switched from Jabber to Skype because Jabber keeps IM history and that is considered a security risk. So instead we get to deal with hit or miss desktop sharing and file transfers, and often not being able to properly connect to the servers any given morning. I think the issue is mostly with our IT, not Skype, but I do know Jabber was dead stable for years. ...not biased at all.
Re: (Score:2)
If you're referring to Skype For Business, I thought it stored all of your conversations in your Outlook profile by default.
Also, if you just switched to Skype For Business then get ready because MickeySoft is killing it slowly in favor of Teams.
Re: (Score:2)
If you're referring to Skype For Business, I thought it stored all of your conversations in your Outlook profile by default.
Also, if you just switched to Skype For Business then get ready because MickeySoft is killing it slowly in favor of Teams.
Yeah, Skype For Business, I forget there are two different Skypes as I use Skype For Business even for calls to my research adviser, though lately we've been using zoom more often as Skype For Business isn't very stable to my college campus either. You might be right about the history but maybe it can be disabled or they prefer the outlook server security? When I go to File->View Conversation History, nothing happens, so I'm thinking the prior.
Yeah, not particularly thrilled with any MS office products
Re: (Score:2)
We recently switched from Jabber to Skype because Jabber keeps IM history and that is considered a security risk.
I'm fairly certain that the Jabber protocol (i.e. XMPP) does not mandate storing message history. I've used Kopete for OTR (end-to-end encrypted) messages, and Kopete lets you disable local logging.
Did you mean some specific server or client software?
Re: (Score:2)
We recently switched from Jabber to Skype because Jabber keeps IM history and that is considered a security risk.
I'm fairly certain that the Jabber protocol (i.e. XMPP) does not mandate storing message history. I've used Kopete for OTR (end-to-end encrypted) messages, and Kopete lets you disable local logging.
Did you mean some specific server or client software?
Yeah, I'm not IT. I just know what other people told me as to why we switched.
Huge difference between "want" and "care"... (Score:3)
There is a huge difference between "bosses around the world don't want it," and "it wasn't something paying customers cared about." (emphasis added for clarity) The former implies (as observed in the quoted summary in the parent thread) that bosses may be actively seeking to eavesdrop; the latter implies that bosses don't care either way, as long as they don't have to pay extra for encryption.
Clearly, the concerns of the actual end-users is that perhaps the former is more likely the case... which probably tends to drive those end-users to other platforms (those which do enable encryption) for any of their more casual interactions. And obviously, when you default to an "unofficial" platform in this fashion, you're not particularly likely to bother going back to the "official" platform just to conduct business with those same people -- except when you're forced. And we all know what happens when you try to force someone to do something that they don't want to do; they pretend to do it, or they only do it just barely enough to get the boss off of their back.
End result: ironically, those "paying" customers may stop paying, if Slack can't actually convince the end-users to use the tool properly... which I would suggest makes this a potentially self-defeating scenario.
I prefer it this way (Score:2)
Tells you everything about Slack (Score:2)
Money money money. Speaking of money, when the boss and the boss's boss are fired and by shareholders for gross and possibly illegal negligence with legally protected data and company trade secrets, I'm sure Slack will pitch in for his lost income and legal expenses.
Why would you listen to bosses? (Score:3)
Re: (Score:2)
Why would you listen to bosses on technical implementation details?
I'm sure the conversations are more like:
Boss: We need comms
Underling: Ok, here's one that's encrypted and one that's not.
B: Which ones more expensive?
U: Well, the unencrypted one. But it's less secure.
B: Thanks
Boss' boss: Great buy the cheaper one.
Priorities of its paying customers (Score:2)
China?
This is why we don't use it. (Score:2)
Specifically for anything sensitive.
It would be fine if we could host it, so the unencrypted bits were in our enterprise (a feature once promised but I think gone from the roadmap.) Also fine would be an option to encrypt the store on their end for just our bit (the encryption doesn't need to be mandatory.)