Build more secure apps with Request Signing & Mutual TLS

Establish more confidence in the security of your apps

Max Feldman
Slack Platform Blog
4 min readJul 18, 2018

--

Illustration by Kelsey Wroten.

Recently we’ve released two new security features — Request Signing and Mutual TLS. Both of these features allow you to create more secure interactions with Slack, so you and your app’s users can benefit from establishing a higher level of trust between customers and your integrations.

In this article, you’ll learn about the difference between Request Signing and Mutual TLS, and when to implement these features for your own apps.

Understanding Signed Requests

Slack uses HTTP requests to notify your app that something has happened. If you’re subscribed to the Events API, your app might receive a request when a reacji has been added to a message. If your app includes a slash command, your app will receive an HTTP request when someone uses your command. Your app may even be notified that it has been granted new resources and permissions. For all of these cases, your app should verify that the request has actually originated from Slack. Without this verification step, an attacker could spoof a request, which could trick your application into performing unwanted actions.

In the past, when an outbound request to an application was sent, Slack included a predetermined secret to establish the authenticity of the request. Now, with Request Signing, Slack sends a signature instead of a secret. This signature is unique to the request and calculated based on the request body, current time, and signature version. This means that even if there is a malicious actor who can alter requests, they can’t fake the signature. Your app verifies this signature to validate the request, and if it’s a match, congratulations! You’ve got an authentic Slack request on your hands. Find more details and in-depth documentation on our API site.

The signing secret, found in your app management panel, is the key to the signature. Without it, a valid signature cannot be created.

Supporting trusted apps through Mutual TLS

Partners and customers want the reassurance that requests they receive truly originate from Slack. Currently, developers can do this at the application layer, but some customers and partners would prefer an even deeper level of security to better protect app servers from attacks, and ensure that security checks are automatically happening across all apps.

When accessing an HTTPS URL, the client verifies server identity using the TLS protocol. Enabling Mutual TLS allows your app to verify the identity of the client (Slack) using the same protocol. This may be useful if you have the ability to configure your own TLS-terminating server, or if there’s value in moving complex parts of authentication outside of your application code.

Better together?

Both Request Signing and Mutual TLS allow verification without sending a secret along with every request, preventing the exposure of long-term secrets — even in the presence of someone intercepting a request or TLS-terminating infrastructure that should not have access to the secret.

However, they are not mutually exclusive! There are certain cases where it may be useful to employ both methods to provide higher security. One example scenario would be if you control the TLS terminator for your application, but the request needs to pass through untrusted infrastructure after TLS termination. Mutual TLS can be employed by your TLS terminator, and your application can later use Request Signing to ensure end-to-end authenticity of a request coming from Slack.

It’s important to note the key differences between the two approaches.

With Request Signing, verification occurs in your application code, making it quick and easy to deploy in your codebase. With Mutual TLS, verification is handled by your TLS-terminating server, which can be easier and less error-prone, since you don’t have to worry about the complexities of authentication within the application code.

Mutual TLS also offers the advantage of mitigating the potential for secret leakage or compromise, as you no longer need to store a long-term secret. Additionally, Slack handles the management of the private key material (and lifecycle), which allows us to perform secret rotation without you ever needing to worry about that.

Get started with Request Signing! We expect to have SDK support soon, but you can implement yourself today. To begin using Mutual TLS, read through the documentation and instructions on our documentation site.

Questions or feedback? Send us a note at devsupport@slack.com or tweet @SlackAPI. We’re excited to see what you build!

--

--