Understanding TLS for REST Services (2024)

Application Programming Interfaces (APIs) act as bridges between applications so they can share data. APIs are fundamental to the complex, interconnected systems, enabling organizations to streamline business processes and reduce redundancies. REST APIs are easy to use and understand because they use the same noun- and verb-based format as HTTP. Simultaneously, attackers know how to manipulate this language, making REST APIs a common attack target.

When securing REST APIs, encrypting the data transmitted between the application and server is critical. By understanding the importance of transport layer security (TLS) for REST services, you can build the foundation of a robust API security strategy.

What is Transport Layer Security (TLS)?

Transport Layer Security (TLS) is a widely used authentication and encryption protocol that establishes a secure communications channel for data-in-transit while ensuring that the client and server can validate one another.

Developed and maintained by the Internet Engineering Task Force (IETF), the TLS protocol encrypts various online communications, like:

Web browsers loading a website
Email
Private or direct messages in social media websites
Voice over IP (VoIP) calls

TLS mitigates risks like:

Man in the Middle (MitM) and eavesdropping attacks, by making data unusable to anyone without the decryption key
Data loss or unauthorized tampering, by using Message Authentication Codes (MACs)
Data forgery, by establishing a way to authenticate clients and servers

TLS vs SSL

Since TLS is essentially the evolution of the Secure Sockets Layer (SSL), people often use the terms interchangeably. Similar to TLS, SSL was a communication protocol that enabled encryption and authentication between servers and applications.

However, when compared to TLS, SSL was:

TLS vs HTTPS

Hypertext Transfer Protocol Secure (HTTPS) is one way that websites can use TLS. Essentially, the website uses the formatting and transmission protocols that allow servers and browsers to communicate then add the TLS security on top of these.

How does TLS work?

TLS relies on digital certificates that the client and server use to authenticate each other and share encryption keys.

TLS Handshake

The TLS handshake is the authenticating communication between the client and server. Currently, the two protocols in use are TLS 1.2 and TLS 1.3

TLS 1.2

With TLS 1.2, the process looks like this:

Client “hello” message: TLS version, identifying string of bytes called the “client random,” and information that the server can use to identify the appropriate key exchange algorithms called “cipher suites.”
Server hello message: TLS/SSL certificate, cipher suite, and identifying string of bytes called “server random”
Authentication: Client verification of server TLS/SSL certificate to prove server’s identity
Premaster secret: Client’s random string of bytes with public key
Server private key: Server decryption of public key
Session keys: Client and server session key using client random, server random, premaster secret
Client “finish”: Message encrypted with session key
Server “finish”: Message encrypted with session key
Symmetric encryption: Completed handshake with continued communication using session keys

TLS 1.3

The primary difference between TLS 1.2 and TLS 1.3 is that TLS 1.3 has a shorter handshake process because it changed the type of key exchange algorithms to more secure ones, reducing the overall number of discrete steps in the handshake process.

The TLS 1.3 process looks like this:

Client “hello”: protocol version, client random, cipher suite list, parameters for calculating premaster secret by assuming it knows the preferred key exchange method
Server master secret: Creation based on client random, parameters, cipher suites, and its own server random
Server “hello” and “finished”: Server response with certificate, digital signature, server random, and cipher suite
Client verification and “finished”: Signature and certificate verification, master secret generation, and “finish” message
Symmetric encryption

Mutual TLS

In a regular TLS handshake, the server and client establish the encrypted TLS connection once the client verifies the server’s information. However, with mTLS:

The client verifies the server’s certificate
The server verifies the client’s certificate before granting access

Why is Mutual TLS used?

With mTLS, both sides of the transaction verify that traffic is secure and trusted, enabling organizations to verify non-human logins, like those associated with APIs. By verifying the client, mTLS mitigates risks arising from attackers sending malicious API requests, like those seeking to exploit a vulnerability

Securing API with Transport Layer Security (TLS)

To secure REST APIs, you often need to configure TLS. While some certain things like the port that the API uses will change, some general processes remain the same.

Determine whether to use an API gateway

API gateways act as an entry point for all API calls and incoming requests. With everything in one location, you can manage your API security security more easily. Typically, these also add another authentication and authorization layer between clients and servers.

Obtain certificates from Certificate Authorities

Both your API server and your client need to have the appropriate configurations.

For the API server, your admin will need to log into it and enable the secure connection by configuring TLS encryption which means obtaining a certificate for the external interface and storing that certificate.

For APIs, you must acquire either a certificate and private key. In some cases, you may be able to use a default key. However, if you plan to implement mTLS, then you need to use a custom domain name.

Configure the trust store

A truststore manages the trusted certificates that the client uses when making an outbound TLS connection to a TLS endpoint so that it can validate the server’s certificate.

If you’re implementing mTLS, you need a complete train of trust across:

CA certificate issuer
Root CA certificate

Additionally, your truststore should support strong hashing algorithms, like:

SHA-256 or stronger
RSA-2048 or stronger
ECDSA-256 or stronger

If you use an API Gateway, then you can automate the certificate validation process.

Configure the keystore

Containing the TLS certificate and private key, the keystore is on the server hosting the TLS endpoint so that it can present the server’s public certificate to the client.

When configuring the keystore, you should consider the following best practices:

Creating a strong, unique keystore password
Backing up the keystore when you change any files containing credentials or local keystores files.
Rotating encryption keys on a regular basis

Graylog API Security: Continuous monitoring with high-fidelity alerts

With Graylog API Security, you gain visibility into your API landscape and how your environment uses them. Graylog API Security captures all request and response details, helping you detect attacks, triage next steps, and document all activities. Using our pre-configured signatures, you can identify common threats and API failures to enhance your overall security.

With APIs organized by domain, you can align your monitoring with the open API specification, including identifying prohibited and deprecated APIs. Graylog API Security automatically discovers the most common types of attacks and failures so that you gain at-a-glance visibility into the most severe issues without requiring you to have deep technical knowledge about APIs. By automatically categorizing API calls into meaningful buckets, like API calls that are successful, leaking, or malformed, you can bring all this data into focus.

To see how Graylog API Security can help you protect your organization, contact us today.