TLS/SSL/Mutual SSL with Web Application and Integration with other Application — A Detailed Guide
Introduction
Data security is one of the key aspect for any application especially when the application is publicly exposed on internet and it carries secured and highly sensitive data like personal information, financial information and so on. When any communication happens over the network, there are various tools and technologies by which data or network packets can easily sniffed and stolen.
The conventional, widely used and effective way to protect data is using cryptography which comprised of two processes; encryption, where data is encrypted by sender to make it unreadable and useless for invaders and when data received by the actual receiver, again a process is performed call decryption which converts the encrypted data to original data.
The computer networks and communication designed on Open System Interconnection (OSI) conceptual model which consists of seven layers. Each layer has defined task and performed by either hardware or software. Transport layer is the fourth layer of OSI which can also be considered as heart of OSI model which is performed by combination of both hardware and software and that is why it is quite significant. The Transport Layer provides a way to implement encryption/decryption while sending/receiving data to/from network.
Let’s understand this with below diagrams:
In Figure 1 & 2, we can see data is sent from one machine to another machine over the network and data is traveling from highest layer (Application layer for Sender) to lower layer (Physical Layer for Sender) of OSI model and then reach to network. The Transport Layer which runs on protocols like TCP, UDP, SCTP etc. provides mechanism to encrypt/decrypt data before sending over network and after receiving from network respectively. This security mechanism applies on Transport Layer so call Transport Layer Security (TLS) and since it is on middle level, it applies to the all high level communication protocol which are based upon this like HTTP, FTP etcetera and make these protocols secure like HTTPS, SFTP.
The TLS is much effective security solution when communication happen via public network where anyone can put data sniffing tool and steal information. Since TLS always transmit data on network after encryption there is no worry about data theft while it is in transit.
In this article, we learn the applicability of TLS in Web Application and Integration with another application with REST based communication from both server and client perspective. We will discuss the conceptual implementation design and implementation perspective with example and sample code.
Terminologies
In TLS/SSL implementation below terminologies are used:
- Server: Server is a technical component which is hosted by the business, gets request from client, process and provide response to client. Example, server which hosts applications like bank application which user uses to do transaction.
- Client: Client is machine & technical component where actual user interacts, sends request to server for processing. Once request processed at server, server sends response to client where user consume the response. Example, browser on machine which is used to interact with web application.
- Cryptography: Cryptography a technology which is used to protect the data. It consists of two processes:
- Encryption: Encryption is a process of Cryptography where actual data is converted into another format using some mathematical algorithms like RSA, DSA, AES etc.
- Decryption: When encrypted data is reached to actual person/system, it is again go through a process called Decryption to convert to original data from encrypted data using same algorithm which used for encryption.
The encryption and decryption logic/algorithm requires a key which is only available to sender and receiver so if data is stolen by anyone else will not get actual data.
This key may be type of:
Symmetric — The same key/string literal which is used to encrypt and decrypt called symmetric key and used with symmetric cryptography algorithm like AES. Since the encryption and decryption performed with single key/phrase/literal (acts like password) the both sender and receiver must know the it. It is simple but since two entities know the same key, it is not used with TLS.
Asymmetric key — In case of asymmetric key, a combination of keys used called: Public and Private key.
- Private Key: A key which is available to the receiver and used to decrypt the data. Since it is private key, there is always a Public key for the given private key and hence used as owner of Public Key. It is available into formats like pem, pfx etc. Mostly, it is available at server. In case of mutual SSL case, client also holds a private key.
- Public Key: A key/certificate which is available at client and used to encrypted data before sending on network. When client sends data, data is encrypted and sent to sever. It is available into formats like crt, cert, der etc.
- Certificate: A certificate is an identification file issued by some issuers to a person/entity and contains various information like:
Issued To — This field contains the name person/entity to which certificate issued
Issued By — This filed provides name of the person/entity who issue the certificate
Valid From and To: Contains from and to date for which certificate is valid
Version — Version of certificate
Serial No — A unique serial number for the certificate
Signature — Signature for the certificate which used to identify the certificate originality
Subject — It contains the Common Name (CN) of the certificate owner
Public Key — A key based upon the algorithm used to generate the public key like RSA-2048, RSA-4096 etc.
Basic Constraints — It contains the constraints like Subject Type, Path length etc.
Key Usages — It has list of usages for the certificate like Digital Signature, Non-Repudiation, Key Encipherment etc.
Subject Alternate Name — Alternate name of the Subject (CN)
Certificate Policies — Policies applicable for the certificate
Thumbprint — A thumbprint for the certificate
- Certificate Authority — Since the certificates are also used for identification, normally certificates are used by entities/organized which are globally known, called Certificate Authority like TrustWave, DigiCert, GlobalSign etc.
There are mainly three types of Certificate based upon the usability:
- Root Certificate — It is the highest level of certificate which is used identify the CA itself as mostly highest level of certificates are for Certificate Authorities only. These certificates are issued for long times like 5–20 years and preinstalled in most of the device certificate manager.
- Intermediate Certificate — These certificate which exists in between the end user/entity certificate and CA certificate and used to validate the trust.
- End User/Entity Certificate — It is the lower level of certificate and issue to the end users/entities who get it issued from the CAs.
Self-Sign Certificate — The certificate generated by using OpenSSL tool by own called self-sign certificate and often used for development and testing environment only. Please refer link: https://github.com/siddhivinayak-sk/mutual-ssl-server-client for Self-Sign certificate commands.
- Keystore: A container to store the public/private key securely protected by passwords. It is available in formats like .jks and .pfx.
- HTTP: Hyper Text Transfer Protocol (HTTP), a protocol based on TCP/IP which is used to provide communication for web applications and browsers.
- HTTPS: HTTP Secure (HTTPS) = HTTP + TLS; When Transport Layer Security applied with HTTP called HTTPS.
- TLS: A security methodology, where data cryptography is applied on transport layer of OSI communication model. There are many TLS versions available since instruction of TLS as TLSv1.0, TLSv1.1, TLSv1.2 and TLSv1.3.
- SSL: Secure Security Layer (SSL) was predecessor of TLS; it was deprecated around 1990. But often this term is used for TLS implementation with web applications or HTTPS communication.
- JKS: Java Key Store (JKS) is a proprietary format to store certificates and keys.
- PKCS: Public Key Cryptography Standards (PKCS) is a format used as key storage and widely used. It is also recommended by OpenSSL forum.
- Handshake: This term is used when client starts communication with server and to the certificate sharing and validation to start encrypted communication.
- Negotiation: When Handshake happen, there are different parameters like TLS version, cipher suits available to client and server are checked and come to a conclusion which version will be used for further communication. This process is called negotiation.
- Cipher Suites: When TLS session established, first handshake process happens between sender and receiver. We already know there are various encryption algorithms are available with different level of padding and hashing; these combinations will make negotiation much complex and therefore, cipher suites are formed which is string of algorithm and other parameters used to make negotiation easier. Example of cipher suite: DHE_RSA_AES256_SHA256
Design & Implementation — Conceptual
In web applications/integration based upon REST, the communication happens with HTTP protocol which by default does not implements the SSL. Below is the diagram depicting the communication between client and server without SSL:
In web application, SSL/TLS can be implemented in following ways based upon the need:
Server Side SSL
This is the basic and simplest implementation of SSL in web application where server implements SSL without any clients’ trust validation with help of a Private Key issued for the server/entity/organization with required details like Subject Name/Subject Alternate Name (DNS on which server is hosted application accessed by client).
This is the basic implementation and most of the web applications applies the SSL in this way only. It enables the Transport Layer Security (TLS) when communication happens with the client and client can also validates the server identity by the certificate shared from the client when connection established. Let’s consider the below diagram:
Let’s understand the basic SSL/TLS communication steps with Sequence diagram:
Below is the detail of sequence diagram:
- Client sends a message requesting setup encrypted session with supported Cipher suits and TLS versions
- Server responds with selected (supported) TLS version at sever end along with public key of server
- Client verifies server certificate and extract Public key from the certificate. It creates a new pre-master-key by encryption using public key and send to server
- Server decrypt the pre-master-key using the private key
- A. Using pre-master-key client creates a shared-secret B. Using pre-master-key server creates a shared-secret
- Client creates an encrypted message by using shared-secret and send to server to verify it
- Server decrypt message by using its private key and negotiated specs and verify the content
- Sever creates an encrypted message with same shared-secret and send to client to verify it
- Client decrypt message by using shared-secret and verify message
Now, handshake completed with shared-secret. This shared-secret will be used to encrypt and decrypt the data for entire communication session.
Note: The Public and Private Keys are example of Asymmetric keys and used only while Handshake process. Once handshake process completed, the shared-secret will only be used for entire session as symmetric key for encryption and decryption. This happens because, asymmetric encryption and decryption requires complex mathematical calculation which is much costly in respect of processing so once handshake completed, symmetric algorithm is used.
To implement this approach, most of the web server provides configurable way to enable SSL/TLS at server level.
Let’s create server and client for testing purpose:
1. Checkout server and client code from: https://github.com/siddhivinayak-sk/mutual-ssl-server-client
2. The certificate, private key and JKS/PKCS files are already generated for testing purpose. In case need to generate your own, follow the readme.txt file available into /src/main/resouces directory
3. Add below two entries into /etc/hosts file to map your localhost to domain name used into certificate
Note: You may need elevated rights to edit hosts file.
4. Change configuration as,
In severs’ application.yaml file:
Comment below properties (as these are used for trust validation):
Enable below properties:
In client’s application.yaml file:
Set below two properties to false (as in basic these are not required)
5. Now, start Spring boot server application. It will open on 443 port, which is default port for SSL.
6. Once server started, start client application and see the console for output
Server side SSL with Certificate Validation at Client
This approach is just extension of basic SSL implementation at server. In this approach, the identity of server is validated at client, whether client is actually the which is expected or not.
This server identity validation is very much required whenever any sensitive data is sent to the server. The server identity is verified by the server certificate (X509 Certificate which is available into the sever SSL configuration). Hence it is always recommended to verify server identity while making call to server. The user who uses browser can also verify server identify from the browsers security/lock icon available at the browser URL input box.
To validate the server certificate, the client maintains a certificate store called trust store which contains certificates of trusted server. When client make request to server and server provides certificate as part of handshake, the certificate is checked whether it is in trusted store or not. If it is not in trusted store, then server is marked as untrusted sever and handshake failed.
Let’s understand it in detail with below diagram:
Let’s setup this approach for testing purpose:
Setup server and client related settings explained in previous section and performed below steps as additional setups:
- Need to add trust store into the client so do the below changes into the clients’ application.yaml. Enable Trust store setting as,
Here enabling trust material will start server validation and the server certificate will be stored into the trust store and its path will be setup with material-path.
2. Now, start Spring boot server application. It will open on 443 port, which is default port for SSL.
3. Once server started, start client application and see the console for output
Note: A trust store file has already been created with server certificate stored in it for testing purpose only. This is just for reference purpose not for actual use.
Mutual SSL
Mutual SSL is an SSL/TLS implementation technique where both transport layer security is added along with client and server identity verification and trust establishment at both side. In simple words, there will be Private Key and Certificate at server end for SSL/TLS then there will be a trust store which will store client certificate and whenever client make a call, server validate the client identity as part of handshake process.
Similarly, Client will also have a Private Key and Certificate as Key material which is used while handshake with server to provide the clients’ identity. Client will also have a trust store which stores the server certificate to validate the server identity at client side.
Let’s understand with below diagram:
In diagram, the client and server both depicted with Key Store and Trust Store.
In case of Mutual SSL, the handshake process also will be change a little bit. Let’s understand the handshake process with below process diagram:
To implement mutual SSL, changes required at both end, server and client. Since, servers can be created and placed at various layers of networking, there are many possibilities for mutual SSL implementation. Let’s go through some of the popular implementation and design:
Basic Implementation — At Server/Micro-Service Level
The mutual SSL can easily be implemented at the server/micro-service level as most of the web servers/containers provides built-in support for mutual SSL for example Apache Tomcat provides configurations based implementation.
Let’s understand with below diagram:
This is the basic implementation of Mutual SSL where Key Store which contains the private key and Trust Store which contains the trusted clients’ certificates are stored with server and the server is access from client directly on HTTPS protocol.
When client makes call to server resource, it also usages the Key Store and Trust Store to send client identity to server and validate server’s identity.
Let’s create server and client for testing purpose:
1. Checkout server and client code from: https://github.com/siddhivinayak-sk/mutual-ssl-server-client
2. The certificate, private key and JKS/PKCS files are already generated for testing purpose. In case need to generate your own, follow the readme.txt file available into /src/main/resouces directory
3. Add below two entries into /etc/hosts file to map your localhost to domain name used into certificate
Note: You may need elevated rights to edit hosts file.
4. Change configuration as,
In severs’ application.yaml file:
Enable below properties (as these are used for trust validation):
Enable below properties:
In client’s application.yaml file:
Enable Key and Trust materials while making call to server.
5. Now, start Spring boot server application. It will open on 443 port, which is default port for SSL.
6. Once server started, start client application and see the console for output
If one wants to configure into Apache Tomcat, follow the below steps:
1. Open Server.xml from Tomcat /conf directory and edit it
2. Configure Key Store and Trust Store in connector as,
3. After changes, re-start the Tomcat. The resource will be exposed on 8443 port
Internal/Gateway — At Micro-Service Level with SSL Pass-through at Ingress
This case is applied when application is deployed in Kubernetes based environment where each application/micro-service deployed in Pods.
In this approach, the application/micro-service running in Pod is only responsible for SSL and Mutual SSL. If application/micro-service is accessed via Ingress the Ingress rules need to be configured with SSL pass-through option.
Let’s understand the implementation with below diagram:
In this approach, the backend micro-service runs on HTTPS protocol and also establish trust from the client side so the Key Store and Trust Store will be present at the backend micro-service. If there is more Pods available for same micro-service, the Store will be present with each instance. The Ingress does not perform SSL offload and when handshake happen, the backend gets the required details in request.
To implement this, the Ingress rules must contain annotation to specify the service backend protocol and SSL pass-through annotation as,
Internal/Gateway — At Ingress Level
This approach can also be taken when application/micro-service is deployed in Kubernetes platform.
In this approach, the backend application/micro-service will be running on HTTP and SSL and Mutual SSL will be implemented with help of Ingress.
Let’s understand this approach with diagram:
In this approach, the backend services will be running on HTTP only and hence no need of Key Store and Trust Store. There are two secrets created into the Kubernetes with the Private Key and for Trust Certificate which client will be using to make call to server.
Here, TLS will be implemented at Ingress so Ingress will be performing SSL and Trust validation of Client. This requires the default functionality of Ingress where SSL off-loading happen at Ingress level and after the handshake the request forwarded to backend service/micro-service for further processing.
To implement this, need to specify additional annotation for TLS and Auth. Use below configuration to setup this approach:
Application Gateway Level
Application Gateway is a web traffic manager and allows traffic routing, blocking etc. for web application’s incoming traffic. Most of the application gateways also provides the traffic enhancement, authentication, attack prevention as well.
If application gateway is available, we can also implement mutual SSL with help of the application gateway. Let’s understand this approach with diagram:
In this approach, the application gateway capability is utilized to do the trust validation for the clients. The TLS/SSL implementation can be done at both gateway level or Ingress level without any issue.
To implement this, need an application gateway like, if application is deployed into the Azure, Azure Application Gateway can be used for this purpose.
Inter Micro-Service Communication — With Mutual SSL
In micro-service based application, it is recommended to implement the mutual SSL where inter-micro-service communication is there to achieve transport layer security while communication.
Basic Implementation
In basic mutual SSL/TLS implementation, the implementation happens directly to the server and client which are going to interact.
Let’s understand the basic implementation with diagram:
Below are the details:
- Each micro-service will implement the mutual SSL server and client based upon the applicability
- Each server (here, micro-service) will have Key Store to store its Private Key and if it is consumed by other technical component then it contains the Trust Store to store the trusted client certificates.
- While communication, the same/different private key and certificate used based upon the setup and arrangement
If mutual SSL configured at server and expected to use by specific users who are authorized for it from browser this is also feasible very easily. Normally, most of the web browser also provide a mechanism to establish the mutual SSL based connectivity. Browsers provide the certificate manager (sometimes with help of underlying OS) where the client can store its private key and to verify server certificate, server’s/CA certificate can be added into Trusted certificate section into Certificate Manager.
Although, this implementation is quite easy as configuration need to change each micro-service where endpoint exposed and where endpoint consumed. But consider the scenario where a number of micro-services are available where Key Store, Trust Store available and need to do certificate replacement. It will require huge effort while changes and testing/verification purpose.
With Service Mesh
It is just little advance where mutual SSL is implemented with a platform to ease the implementation at each application instance/micro-service, this platform called Service Mesh.
Let’s understand the Service Mesh through the diagram:
Service Mesh platform provides a software solution with a component called proxy which included at each service. Now with Service Mesh, the communication happens only via proxy to any external client like other micro-service or other type of clients.
This proxy is fully configurable and controlled by Service Mesh platform with declarative configurations. This means, the developer does not have to do any implementation for SSL/TLS and only need to focus on the actual business functionalities. When micro-service deploys, for each service a web proxy is created by Service Mesh automatically and run as side car. And whenever any call is made to the micro-service the traffic will go via web proxy only where all SSL/Mutual SSL related setup.
Let’s understand this with detailed diagram:
Here we can see, each micro-service has proxy as sidecar which are managed by the Service Mesh by the declarative configurations.
There are many Service Mesh available by different vendors e.g. Istio by Redhat, Consul by HashiCorp, Linkered etc.
Business Benefits
Data security is one of the key aspect for web applications which must be taken care of properly to avoid data theft. If application is hosted in a way where application uses public network or Internet, then need to implement security for data when it is in transit otherwise data can be sniffed/stolen by the intruders.
This data in transit security can easily implemented with TLS/SSL implementation to avoid such theft. In any case data must be protected while in transit but it becomes essential when application process data like personal data, financial data etc.
The approaches discussed here, can be picked up based upon the application architecture and level of implementation can also be chosen as per applicability to provide proper protection from data theft directly related to the business.
Conclusion
The TLS (often called SSL in web application context) is much popular and effective in transit data protection mechanism for web application and hence it is recommended to implement. It is also required to evaluate, what level of TLS implementation required like client validation required or not, server validation at client required or not and on what level implementation is required.
The approaches discussed here can be implemented with different programming languages and platforms as well.
If any REST based integration required, it is highly recommended to use Mutual SSL for the communications to avoid risk of data theft and reliable communication by applying identity validation of both client and server.
References
- Azure Application Gateway — https://docs.microsoft.com/en-us/azure/application-gateway/overview
- Service Mesh — https://www.redhat.com/en/topics/microservices/what-is-a-service-mesh
- SSL Client and Server Implementation — https://github.com/siddhivinayak-sk/mutual-ssl-server-client
- Kubernetes Ingress — https://kubernetes.io/docs/concepts/services-networking/ingress/
- Open SSL — https://www.openssl.org/
- Java Key Tool — https://docs.oracle.com/javase/8/docs/technotes/tools/windows/keytool.html
- Ingress with Client Auth — https://kubernetes.github.io/ingress-nginx/examples/auth/client-certs/
- Azure Application Gateway with Mutual SSL — https://docs.microsoft.com/en-us/azure/application-gateway/mutual-authentication-overview
Common Q & A
Steps to open and verify certificate in Web Browsers:
1. Open URL into web browser
2. In URL input box, there must be a lock/secure icon showing if web application usages HTTPS (SSL), click on the icon, a popup will be show as,
3. Click on Certificate, the certificate will be opened where issuer, issued to and validity can be verified.
Steps to check Certificate details:
- Open certificate by double clicking the certificate, a popup will be opened as,
It has general tab where, issuer, issued to and validity displayed.
Apart from this there are two more tabs details and certification path where one can get the detailed information about the certificate as,
The Certification Path tab displays the certificate hierarchy from root -> intermediate -> user certificate.
2. If certificate status is OK means certificate is valid as per current trust manager.
Check certificate detail on Command Line
This requires OpenSSL tool, download and install OpenSSL tool and run below command:
openssl x509 -text -noout -in certificate.crt
How to generate Self-sign certificate
This requires OpenSSL tool, download and install OpenSSL tool and run below command:
#1. Create Private Key and Certificate for Client
#Step 1: Generate Public Certificate and Private Key
openssl req -x509 -nodes -days 730 -newkey rsa:4096 -keyout client-private-key.pem -out client-certificate.crt -config req.conf -extensions ‘v3_req’
#Step 2: Crete PKCS with generated certificate and private key
openssl pkcs12 -export -out client.p12.jks -inkey client-private-key.pem -in client-certificate.crt
#Step 3: Import Server Certificate into JKS file
keytool -importcert -file server-certificate.crt -alias servercert -keystore client_truststore.jks
#2. Create Private Key and Certificate for Server
#Step 1: Generate Public Certificate and Private Key
openssl req -x509 -nodes -days 730 -newkey rsa:4096 -keyout server-private-key.pem -out server-certificate.crt -config req.conf -extensions ‘v3_req’
#Step 2: Crete PKCS with generated certificate and private key
openssl pkcs12 -export -out server.p12.jks -inkey server-private-key.pem -in server-certificate.crt
#Step 3: Import Server Certificate into JKS file
keytool -importcert -file client-certificate.crt -alias clientcert -keystore server_truststore.jks
Note: The req.conf can be downloaded from: https://github.com/siddhivinayak-sk/mutual-ssl-server-client/tree/main/mutual-ssl-client/src/main/resources
How to import PKCS12 into existing JSK
keytool -importkeystore -srckeystore cert.p12 -srcstoretype pkcs12 -srcalias 1 -destkeystore keystore.jks -deststoretype jks -deststorepass 123456 -destalias own
How to convert JKS to PKCS12 format
keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore_p12.jks -deststoretype pkcs12
How to convert Certificate and Private key into PKCS12 format
openssl pkcs12 -export -out client.p12.jks -inkey client-private-key.pem -in client-certificate.crt
About the Author
Sandeep Kumar holds Master of Computer Application degree working as Java developer having 10+ years of working experience. He has experience designing and development of enterprises applications into various domains like education, content, laboratory, and banking; got various appreciation for providing solutions including spot appreciation for Glassfish to JBoss migration project. He secured Google Cloud Developer certificate and participated into OCI trainings. He is a part of HCL-ERS platform as Sr. Lead developer.
