Tips for API Security : 1 Of 12 Use HTTPS

The number of security breaches on the Cloud grows exponentially each year. Security breaches target all kinds of applications from a simple website to API driven functional deployments. Cloud Architects should deploy tools and mechanisms to prevent breaches and secure their software assets and data. In a series of posts we present the way we build in application security in the SaaS products we make.
Anyone who has used the internet would appreciate the need for using HTTPs for transactions on the web. The same goes for API. Enterprises hosting API's on the web should consider using HTTPS to host the API's. HTTPs is enabled on the webserver. To enable HTTPs we deploy a SSL certificate from a trusted Certificate Authority and configure the webserver to use this certificate.

SSL Certificates can be purchased from a Certificate Authority for a fee. Depending on the scope of coverage the Certificate Authority offers three types of Certificates
    1. Single Domain - The certificate can be used to protect one domain like anybank.co.in
    2. Wild Card -  The certificate can be used to protect a domain like anybank.co.in and its sub-domains like ab-comp-ui.anybank.co.in
    3. Multiple Domains - The certificate can be used to multiple domains like anybank.co.in, sastratechnologies.in, sastratechnologies.net etc.

The Certificate Authority offers three types of validation 
    1. Domain Validation - The organisation purchasing the SSL certificate must prove that they own the domain. This is done by creating a CNAME or TXT record on the DNS server
    2. Organization Validation - This validation is stringent and is usually manual and involves the Certificate Authority personnel visiting the premises of the Organisation purchasing the SSL.
    3. Extended Validation - This validations involves a full background check of the organisation. 

To procure the SSL the organisation should generate a Certificate Signing Request. The CSR request below generates the CSR for this domain that is anybank.co.in.

sridhar@SastraTechnologies:~$ openssl req -newkey rsa:2048 -nodes -keyout anybank.co.in.key -out anybank.co.in.csr

During the process openssl requests for some data that will be incorporated into the CSR

Country Name (2 letter code) [AU]:IN
State or Province Name (full name) [Some-State]:Tamilnadu
Locality Name (eg, city) []:Kilpauk
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Sastra Technologies Private Limited
Organizational Unit Name (eg, section) []:AnyBank Suite
Common Name (e.g. server FQDN or YOUR name) []:anybank
Email Address []:websolutions@sastratechnologies.in

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

We can now head to a Godaddy or similar Certiifcate Authority and purchase a certificate. During the purchase process we need to upload the CSR that we generated and the certificate is issued. The certificate can now be deployed onto a webserver. Our product servers for the AnyBank suite are running Nginx on Ubuntu so we shall use them as an example. Before we deploy the certificates we will make changes to the firewall to allow HTTPS traffic. This can be done using the following

sridhar@SastraTechnologies:~$ sudo ufw allow 'Nginx Full'
sridhar@SastraTechnologies:~$ sudo ufw delete allow 'Nginx HTTP' 

The SSL Certficate comes in two files
    1. anybank.co.in.crt that contains the certificate for the domain
    2. internediate.crt that contains the internediate certificates of the CA
These certficates have to be chained into a single .crt file. The file is then copied to the appropriate directory. For Nginx to read the certificate and switch to HTTPS we need to make changes to the domain configuration files to include the following lines.

server {
    listen 443 ssl;
    server_name anybank.co.in;
    ssl_certificate /home/ab-comp-ap/anybank.co.in.chained.crt;
    ssl_certificate_key /home/ab-comp-ap/anybank.co.in.key;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
    ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
}

Having done this we will need to redirect all HTTP traffic to use the certificate. To do this we add the following directives to our Nginx configuration.

server {
    listen 80;
    server_name anybank.co.in;
    rewrite ^/(.*) https://anybank.co.in/$1 permanent;
}

With this all visitors will be switched to the secure site. HTTPS offers the first layer of protection to API's by ensuring that the transmission between the browser (client) and server is secure. Though this article mentions that the SSL certificate is installed on a webserver there are instances where the webserver is behind a reverse proxy like HA Proxy, Squid or Varnish  (even Apache or Nginx are sometimes deployed as reverse proxies) in such cases the SSL certificates have to be deployed on the reverse proxies a process sometimes called “SSL termination”. Some enterprises have network switches that can take a SSL certificate in such cases the SSL certificates have to be deployed on these switches or rather the SSL’s have to be trerminated at these network switches. For additional security the netwok switch also offers port natting where the traffic on an incoming port is routed to an outgoin post before it reaches the backend servers.

However this is only the first step in API security. In the subsequent articles we will look at other tools and mechanisms to secure API's.