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
- 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:
- Slower: requiring more steps and cryptographic key exchanges
- Fewer alert messages: warning and fatal error messages but not close notify
- Less complex cryptography: outdated algorithms for generating MACs, key exchanges, validation, and bulk encryption
Due to the security issues, SSL (along with TLS 1.0 and TLS 1.1) was formally deprecated in 2021.
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.
