Nowadays, it is not hard to boot up an API and put it in the cloud. There is an abundance of tutorials, YouTube videos, and various articles on how to do that. However, one big gap that many developers, mostly those who are new to creating backends, tend to miss when it comes to creating APIs is security.
Security is one of those topics that we know we should implement but do not. Why? Perhaps it’s because we fall into the mentality that it won’t happen to us. The hacks, cracks, and security-related fiasco that make the headlines is something that happens to everyone else.
When you do this, you are basically playing Russian roulette with your data, customer trust, and long-term business stability.
TLS and SSL are two very simple and industry-standard ways of increasing security on your backend application. It’s not much of a restricted access area if others can easily see your username and password. The protocols allow for an automated method of content encryption, making restricted accessible spaces of your application actually what it is.
But before we get into securing your application with TLS and SSL, let’s start with an introduction of what it actually is.
HTTPS, TLS, and SSL
By default, communication on the Internet with a client is performed through the default HTTP protocol. HTTP is regarded as insecure because the client directly communicates with the server in plain text. There is no encryption involved, which means that whatever is sent over the server is accessible and easily readable by whoever intercepted it.
This is done through various techniques such as eavesdropping, which is a process where HTTP packages are accessed whilst in transit between devices or from between the client to the server.
HTTPS stands for HTTP Secure, which is also known as HTTP over SSL or HTTP over TLS. SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are protocols responsible for encrypting content.
The way SSL works is that they use an SSL certificate generated by a trusted third party called a Certificate Authority. This certificate serves as a way to verify and identify the identity of the server and if the packages sent and received to and by the server have been tampered with.
The way HTTPS works are that either TLS is enabled on your server to create the encryption and decryption of data. It is good to note that TLS is the successor of SSL, but both terms are used interchangeably due to what they achieve as an end result — encryption and decryption of data. When you buy an ‘SSL’ certificate or generate your own, you are doing so with both SSL and TLS protocols attached to it.
Encryption and decryption turn plain text to and from the ciphertext. There are two ways HTTPS can be achieved and they are symmetric and asymmetric encryption.
Symmetric encryption is when the same key is used for both encryption and decryption. This key is the only one that keeps your data secure and therefore needs to be kept private.
Asymmetric encryption is when there are different keys used for encryption and decryption. This is the preferred form of encryption because securing your data can be done in a public space before it leaves the client. The public key is not a vulnerable entity as it is used to encrypt only. The matching private key is often kept on the server, away from external accesses and is used to decrypt the incoming encrypted content.
Asymmetric encryption is also the preferred method for HTTPS security because it is harder to crack and the decryption process is often in a secured space. The client often sits in a public space, meaning that if you have symmetric encryption, your private key can potentially be exposed and rendered useless as a result.
However, with asymmetric encryption, it doesn’t matter who sees the public key. The purpose of the public key is to create an encrypted message. This key cannot be used to reverse the process and therefore decrypt the potentially sensitive information.
This leads us to: how do we activate HTTPS onto our servers? First, you start by enabling TLS.
TLS in Apache
To enable TLS onto your Apache server, proceed with the following steps:
- Go to the server configuration file in your Apache server.
- For Ubuntu, this can be found in /etc/apache2/apache.conf
- For CentOS based systems, this can be found in /etc/httpd/conf/httpd.conf
- For virtual hosts, this can be found in /etc/apache2/sites-enabled and /etc/httpd/sites-enabled
- Modify the SSLProtocol entry to SSLProtocol all -SSLv2 -SSLv3 -TLSv1
- Restart Apache via the command service apache2 restart or service httpd restart, depending on your server’s configuration. This will enable all security protocols available and disable SSL v. 2.0 and v.3.0, and TLS v. 1.0
Why do we need to disable SSL v. 2.0 and v.3.0, and TLS v. 1.0? Both SSL and TLS are cryptographic protocols that provide data authentication and data encryption. It should be noted that SSL 1.0, SSL 2.0, and SSL 3.0 have all been deprecated due to age. While SSSL, they are no longer considered secure due to the types of keys they use and ease of key crackability. If your server uses any of these, most modern browsers will issue a security warning through a line through the padlock or HTTPS in the URL bar.
TLS for Tomcat
To configure TLS for Tomcat, proceed with the following tests:
- Find and edit the configuration file TOMCAT_HOME/conf/server.xml
- Modify the entry the following entry to the following:
- Restart Tomcat.
TLS for Spring Boot
Go to application.properties of your Java Spring Boot application and add the following properties:
Or, you can update the Embedded Servlet Container Factory to add/remove protocols as per below:
SSL Handshake Exceptions
Every now and then, you might get an exception on your SSL handshake. Here is what they mean:
Your SSL cert isn’t trusted, or a bad certificate has been installed. The fix is to get a new one.
To fix this, you can load a Truststore in Java using System properties, JVM arguments, or bean on server startup to load the stores using Trust material.
Your TLS versions are mismatched.
In addition to HTTP being highly insecure and prone to potential data security issues, it also penalizes your SEO rankings. This is because Google flags HTTP sites as insecure, making it an untrustworthy source for data security.
It is also good to note that enabling TLS/SSL is different from installing the certificate. The certificate serves as the key to encryption but TLS/SSL is the actual protocol that applies the keys to the data for encryption and decryption. When an SSL certificate is present, it triggers the TLS protocol, which in turn proceeds to encrypt/decrypt your data before it gets transferred.
While TLS and SSL are two different protocols, the difference between them isn’t that big. The theory behind how both works are similar and both achieve the same effect — to create a secure server for your application and facilitate a space where data can safely move through. What TLS/SSL refers to is the handshaking process required to ensure authentication. It doesn’t actually do the encryption or authentication itself — but rather set up the required ports to facilitate this process.
When TLS/SSL is implemented, an attacker can only see the IP, the port, and the size of the data packets being sent and received. The contents inside remain safe and secured, giving your users peace of mind while keeping the data safe from unwanted eyes.