
Slack enables customers to control their encryption keys in enterprise version - bookofjoe
https://techcrunch.com/2019/03/18/slack-hands-over-encryption-keys-to-regulated-customers
======
jpalomaki
Maybe this is more interesting than I initially thought. I was thinking this
would just the encryption keys used to store the information for your whole
organization Slack account. Instead, the keys seem to be much more granular,
since you can revoke access to a single file, specific channel, workspace or
organization level. [1]

I see one benefit of this being able to securely throw away data. Like if you
are doing work for customer XYZ and chatting about it on the corresponding
channel you can throw away the keys for the channel when the project ends.

Wonder how all this granularity works together with the search functionality.
Or maybe they maintain per channel search index that can be covered by a
separate key.

[1] [https://slackhq.com/enterprise-key-
management](https://slackhq.com/enterprise-key-management)

~~~
paulddraper
> Wonder how all this granularity works together with the search
> functionality.

Having implemented a similar system, I too greatly wonder that this.

My guess is they keep it in memory (e.g. ElastiCache) and populating the cache
would require the keys.

------
geofft
This 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.

~~~
femiagbabiaka
The article says it’s only open to enterprise customers. Computing freedom you
have to pay a ton for is not really freedom. It’s really not even close to the
control of IRC.

~~~
geofft
Is it not worth Linux running on mainframes because mainframes are expensive?
Is it not worth Kerberos being free software because the only real users of
Kerberos are enterprises?

Computing freedom for anyone is computing freedom, and contributes to a norm
of user control instead of service provider control. This step is a very small
step, and it only affects a few users. But it's still a step in the right
direction.

(Something self-hosted like IRC is a much better step, and I'm glad there are
free software/on-prem direct Slack competitors now, too. That's also a step in
the right direction!)

~~~
femiagbabiaka
Both of the technologies you named as examples are free and open. Anyone can
inspect them and deploy them on their own. Slack isn’t like that
unfortunately. This is a move to add another feature that will attract
enterprise customers, I would doubt that even Slack themselves would proclaim
this as a move towards greater software freedom.

~~~
pmart123
I agree that this move is articulating enterprise customer demands rather than
demonstrating greater software freedom. I don’t view this as unfortunate
though. Slack is a productivity and collaboration product versus a utility
like a low level database or encryption method. As such, many users and
businesses want to pay for support, added features,
hosting/availability/backups. It is better to have someone having to pay Slack
a lot for power features than have a bunch of targeted ads in Slack. The buck
stops somewhere.

------
tmaly
The title of this post makes it sound like a bad thing, but in regulated
industries like Finance,

firms are required to produce chat transcripts of the traders to regulators.
Slack would be unusable in this industry if the firms could not capture all of
the chat logs.

~~~
black-tea
Funny because I know large financial companies that have been using Slack for
years.

~~~
ddoolin
I believe you can still provide chat transcripts from Slack without managing
keys yourself.

~~~
seqastian
and you can still intercept all the SSL if you just roll out your own certs to
all the workstations and the firewall opens everything..

~~~
ska
Isn’t this standard practice in some industries ?

------
ds
I 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.

~~~
exabrial
I thought it was rather difficult for an admin to view private messages on
Slack? Last I checked you had to apply for this kind of access, on your own
account.

~~~
erichurkman
They are only secure so far as everyone in the DM or private channel is
employed. The company can always take over old accounts and get access to DMs
that way.

~~~
morpheuskafka
If everyone has to use corporate email addressees they could just take over
the emails temporarily to reset the password. If they really cared they could
do so without the user ever knowing. They could also put language in their
employee handbook or contract saying that you have to give them your password
and fire for refusing... however, I fail to see how any of this is an issue
since this is the company Slack and they have the right to see how people are
using it.

------
aboutruby
One good security feature would be to not give the user's email address by
default to apps you connect Slack to.

(And then have them disclose it to every user...)

~~~
paxys
Isn't that how it already works? Apps have to ask for the email scope during
install and you have to approve that individually for the app to get access to
your email.

------
amaccuish
Isn't this just shifting partly your trust from Slack to Amazon?

~~~
fearbeer
I think it's very smart of Slack.

AWS Encryption SDK[1] is a well designed, battle tested data encryption
library. Amazon KMS is a well audited service used by AWS to manage all sorts
of keys and even supports external HSM integration.

For slack to build all this from the ground up would be time consuming. Hard
part being 3rd party validation, penetration testing and certification.

[1]: [https://docs.aws.amazon.com/encryption-
sdk/latest/developer-...](https://docs.aws.amazon.com/encryption-
sdk/latest/developer-guide/introduction.html)

~~~
jcims
Yeah I don't really care about Slack, it's banned at work.

However, this pattern is good and IMHO should be adopted by SaaS orgs that
want to appeal to enterprise/regulated customers. We have a few vendors that
we're sort of pressing in this direction, and a few have come to us with
similar architectural proposals to address GDPR.

Specific to AWS it would be even better of the service allowed for the
customer to host the CMK in their own account so they can choose to import key
material if they like. This has some downstream implications on what you can
do with the key vs. Amazon-generated CMK which may be advantages in some
cases.

~~~
dlgeek
> Specific to AWS it would be even better of the service allowed for the
> customer to host the CMK in their own account so they can choose to import
> key material if they like.

Looks like it does, based on [https://aws.amazon.com/blogs/apn/control-access-
to-your-data...](https://aws.amazon.com/blogs/apn/control-access-to-your-data-
with-slack-enterprise-key-management-and-aws-kms/)

"With Slack EKM, you can use KMS in your own AWS account to create a Customer
Master Key (CMK) that always stays under your control. Then, using key
policies, you grant Slack access to use your CMK to generate and decrypt data
keys."

~~~
jcims
That's cool! Thank you for digging into it.

------
bearforcenine
One thing I'm not totally clear on after reading the article is which AWS
account the AWS KMS resides. Is it Slack's AWS account or the customer's?

~~~
whoisthisfor
[https://slack.engineering/engineering-dive-into-slack-
enterp...](https://slack.engineering/engineering-dive-into-slack-enterprise-
key-management-1fce471b178c)

This shows the KMS key is in the customer's AWS account.

------
roemance
Related article from last fall discussing why Slack was supporting EKM rather
than E2E encryption: [https://motherboard.vice.com/en_us/article/kzj5xn/why-
slack-...](https://motherboard.vice.com/en_us/article/kzj5xn/why-slack-doesnt-
have-end-to-end-encryption-boss)

------
lvs
Just 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?

~~~
paxys
The key store lives in the customer's AWS account, and they can revoke keys or
complete access at any point.

------
l9k
How does it compare to Symphony [1]? They want to get the financial market
companies, but a lot of them already have their own solution.

[1] [https://symphony.com/](https://symphony.com/)

~~~
Can_Not
Can you elaborate on why you are asking how a chatroom service compares to a
webapp framework?

~~~
esnard
You're definitely confusing with Symfony, the PHP framework. As others pointed
out, Symphony is a Slack competitor.

~~~
andylynch
I would still say Symphony’s target is Bloomberg. Despite Symphony’s good
progress so far, Bloomberg are still far ahead in market share and their
network is a great moat which makes it very hard to substitute, also given
that onboarding new platforms across financial firms is a huge challenge even
when you aren’t pushing against network effects benefiting your main
competitor.

------
jacekm
I am curious, does this mean that Slack will not be able to read messages of
such organizations? I.e. the keys will be known to organizations only and
Slack will have no access to them?

~~~
paxys
Slack will have temporary access to messages (in transit on their backend),
but if the keys are revoked by the organization then yes Slack cannot see
them.

------
vprasanth
So this basically means within an enterprise instance of Slack -- "your"
messages can be decrypted and made available for consumption if required?

------
ETHisso2017
Paging MitchellH here, but how does this capability intersect with HashiCorp
Vault?

------
013a
The most surprising thing about this article isn't the article; its the
comments in here, and the surprising number of people who have no clue how
Slack works or how corporate/enterprise regulation & compliance works.

~~~
jvannistelrooy
I have no idea how corporate/enterprise regulation & compliance works in
relation to Slack. Could you elaborate?

~~~
aerophilic
In a past life, I worked as part of a legal regulatory IT function.

What it boiled down to is you have to be able to track _every_ communication
you can, and depending on the jurisdiction, you had to keep it around for 7-25
years.

Not only did you have to keep it around, you had to provably keep it in such a
way that it couldn’t be “sabatoged”, generally this meant you had to store it
on “WORM” (Write Once, Read Many) storage.

The basic rationale is because of the $$ involved, you wanted to make sure no
one was a) insider trading, b) defrauding investors, c) defrauding the bank.

Banks are pretty good at these types of controls.

Example controls they do:

1\. You can’t trade outside of their monitored platform

2\. You are mandated to take a vacation of at least 2 weeks every year (once
you reach a certain level), the idea being that any “off books stuff” you may
be doing would get exposed.

3\. They regularly “flag” specific keywords, and not just the obvious ones, to
identify bad actors. I won’t go into details, but it is much more robust than
you think.

Just my 2 cents...

Minor edit: spelling

~~~
lenomad
> You are mandated to take a vacation of at least 2 weeks every year (once you
> reach a certain level), the idea being that any “off books stuff” you may be
> doing would get exposed.

That's an interesting way to fix a problem!

------
kop316
Out of curiosity, does Slack allow a single person multiple Screennames? I see
a scenario where a single person can have different handles, so personal
communication doesn't overlap with work related communication. But the article
does not make that clear.

~~~
Svoka
I think with Slack you register new account to every workspace you join. I
don't think it even have single account for everything concept, and you'll
have to get a new handle everywhere you join.

------
nukeop
At this point, between no encryption, horrible clients, mistreatment of irc
users, and questionable corporate behavior there's nothing in Slack that's
worth saving it for me. Superior free software alternatives exist that bring
the same or better functionality while also giving the user full control.

~~~
phatbyte
Which free alternatives?

~~~
kemonocode
Matrix, Mattermost, Rocket.Chat, and that's just off the top of my head. All
three are free (as in speech) and aren't terribly hard to set up on-premise or
spin up a container for somewhere else.

~~~
ensignavenger
Zulip is a great choice, too.

------
tyingq
Reads more like _" Hands over control to any customer that will pay for
it."_[1]

I wonder if the UI shows the employees that their employers have the keys.

[1] Edit: as opposed to only regulated customers. Also, there's an
upcharge...you don't automatically get control.

~~~
jerf
Are you saying you had some sort of presumption of privacy on a corporate
Slack account?

If you did, you had it in error.

If I am reading this right, this actually reduces your exposure as an
employee. Instead of your employer _and_ Slack having full access to
everything you do on that account, now your employer has full access but
Slack's access is reduced substantially. (If the setup is working as I expect,
Slack will still get metadata.)

~~~
tyingq
I don't know slack internals. but I assume the employer having the key means
that they now have a way to rewrite history in a way that looks
cryptographically correct.

~~~
eitland
Ok, lets just make this clear:

Slack is not the tool you'd want to use for anything but the most innocent
work-related messages.

For that it is kind of usable, not good but one of the better that will get
approved by management.

~~~
tyingq
I didn't suggest it was.

Again, I don't know the internals. But generally, an entity that has keys can
forge messages. There's an incremental difference between the ability to snoop
and the ability to forge. There's docs on the slack API, but none for the
protocol, and not much is said about the new functionality.

It's certainly possible that was already there via other means, but a change
in key control seems significant enough to warrant a UI indicator to me.

~~~
jerf
"But generally, an entity that has keys can forge messages."

It depends on how it's structured, and with the most natural structure, this
wouldn't be true. You'd be able to forge a message with the keys to exactly
the same degree that you can forge a message coming from your coworker in
Slack right now; short of social engineering to steal their password, anything
else that would allow you to do that right now would be a major security
vulnerability in Slack. And, more to my point, one that could be fixed.

Private keys here would be adding a layer of protection and making it harder,
not easier, to forge anything.

Of course, an employer today could also claim to have evidence that you sent X
to person Y, but Slack's own records would show that you didn't.

They'd have to go out of their way to make it so that merely holding the
encryption key would allow you to fully forge messages.

Generally speaking, this is not _adding_ power to the system, it's actually
_removing_ it. The reason why enterprise customers want this feature is not to
give the customer more power, it's to remove power from Slack, because without
this feature, _Slack_ (not your employer) could forge messages. Assuming they
implement this key stuff securely, this would _remove_ the power to forge
messages from Slack, and your employer would continue to not have it.

~~~
atomical
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.

~~~
fphhotchips
No it doesn't! Employers have been able to read messages on Slack for ages
now.

~~~
atomical
Oh, whoops. I guess they caved to pressure.

------
maxehmookau
Only available for an "additional fee" for Enterprise users. Cheeky.

Also, Slack, I'd like a native MacOS app please.

~~~
morpheuskafka
It's only needed by large, highly regulated businesses, and it only works for
self-hosting obviously.

~~~
Androider
Slack doesn't provide a self-hosting option at any tier. This allows you to
host the encryption key in your own AWS account's KMS service, which Slack
then (running in Slack's own AWS account) then queries.

