TLS/SSL Explained

What is TLS and SSL Protocols?

Both SSL (Secure Sockets Layer) and TLS(Transport Layer Security) are cryptographic protocols that provide security over a network. They are widely used across different applications. SSL had a number of vulnerabilities, and hence, TLS was introduced as an updated version of SSL in the year 1999. SSL has been deprecated by the Internet Engineering Task Force (IETF) in 2015. Therefore, you should have TLS protocol enabled for your applications. You will still see a lot of SSL terminology being used across many organizations until people get accustomed to TLS.

TLS/SSL enabled servers will have two main additional duties

1. Trust: Server application who serves the information to the "clients" needs to obtain trust by the clients. One way to achieve this by attaining TLS certificate from a globally trusted Certificate Authority, whom client has trust in.
2. Secure data: data exchange between client and server needs to go through a secured channel by "encrypting" the messages while it is transit.

Now we know the purpose of TLS/SSL, lets try to understand "How" this Trust and Secure data transfer happens between client and server.

Before we jump on to how TLS certificate works, lets understand what is Symmetric and Asymmetric Encryption. This would help understand the TLS completely.

symmetric Encryption: (data encryption and decryption happens with a common "secret_key" ): In this case Client and Server holds the same "secret_key" to encrypt and decrypt the information. This is light weight and fast, since the size of the key is small, we can transfer more data with this approach. AES(Advanced Encryption Standard) is one of the common algorithms used for symmetric key encryption/decryption.

down side of this mechanism is, for the first time client has to send the "secret_key" to server safely to avoid Man In the Middle(MiM) attacks. which is not easy.

Asymmetric Encryption: (Client Encrypt with Public key and server decrypt with private key): In this case server generates a special private and public key pair, any messages encrypted with public key can only be decrypted with related public key.

public key would be shared to the clients and private key will be put in secret place at server side. Client would use public key to encrypt the information and server uses related private key to decrypt the information. since the size of the public key is more we would not be able to send large messages hence slow. RSA is one of the popular algorithm used to create Asymmetric keys

But this mechanism has a down side too that only client can send information to server securely, but server can not talk to the client.

There is a technique used to share symmetric key to the server for the first time, by using Asymmetric key approach. once the symmetric key reached the server safely, all the subsequent messages could be transferred using the symmetric key which is light weight and fast.

Steps involved in getting the Certificate signed by CA.

1. Server application (assume it is a "bank") request Intermediate Certificate Authority (ICA) by providing company name, address, email, domain and other details. This whole process may take 24 to 72 hours. Root CA will validate the below details before it provides a certificate to the requester.

Note: Intermediate CA is root CA authorized digital Certificate provider. certificate cost varies in attaining and managing the certificate between root CA and Intermediate CA.

• verifying the legal, physical and operational existence of the entity
• verifying that the identity of the entity matches official records
• verifying that the entity has exclusive right to use the domain specified in the EV SSL Certificate
• and verifying that the entity has properly authorized the issuance of the EV SSL Certificate.

Now server has CA provided certificate document, and it can be shared with the client to acquire confidence and have business with them. But how does server safely ship this certificate to the client browser or application. what if the document is hacked and corrupted by the MiM in transit. after all it is just a document with server details and authenticity.

The solution to this is "Digital signature"

Digital Signature is a private key encrypted value of the Cryptographic hash of the CA provided certificate document.

There are few Mathematical Hash algorithms to generate a Cryptographic Hash value from any kind of data. few of them are

MD5 ( 32 char, 128bits )
SHA1 ( 40 char, 160bits )
SHA256 ( 64 char, 256bit ) --> most popular

Below are the Properties of the Cryptographic Hashing algorithm (lets take SHA256 as an example) 

1. for Any kind of input value (text, file, mp4, jpg, pdf) it must generate 64 char (256 bit) unique value.
2. No Two hash values should be same for any two different inputs
3. hash value should be same for the same input, for any number of times we generate.
4. No one should NOT be able to recover the original input value from the hash value.

Now server can generate a hash out of the actual certificate file and encrypt the Cryptographic hash value using the private key to generate digital signature( aka cypher text) and send it to client.

On the client side two steps would be performed.

1. he can decrypt the digital signature using the public key and store the value to h1.
2. Generate the Cryptographic hash using the same certificate and using same algorithm and store the value to h2.

 if both h1 and h2 hash values are same then we can certainly tell that the certificate has not been modified in transit and it actually belongs to the server what clients is talking to and client can share the "Pre Master Secret Key" for subsequent data transfer.

Below is the Mathematical representation of sample Cryptographic Hashing

m: message, c: cypher text, n: common constant , pb: public key value

pt: private key value

c = f(m, n, pb)

f’(c, n, pt) === f’(f(m, n, pb), n, pt) === m

Note: fx is a hash function on client side and f’x is a has function on server side, where fx === f’x for all data transfers

Here is the pictorial Representation of SSL handshake between Client and Server using the certificate

SClient and Server SSL Handshake

2. Important point to remember is, in all the TLS/SSL handshake Public Key playing vital role and it has to be safely placed at client end. so most of the web browsers and operating systems pre-installed with major Root Certificate authority and Intermediate Certificate Authorities certificates with public keys as shown below from chrome.

Sample Certificate details can be viewed using openssl command line (check the highlighted areas):

bash$ openssl x509 -inform der -in ca_certificate_sample.cer -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            08:3b:e0:56:90:42:46:b1:a1:75:6a:c9:59:91:c7:4a
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root CA
        Validity
            Not Before: Nov 10 00:00:00 2006 GMT
            Not After : Nov 10 00:00:00 2031 GMT
        Subject: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:e2:3b:e1:11:72:de:a8:a4:d3:a3:57:aa:50:a2:
                    8f:0b:77:90:c9:a2:a5:ee:12:ce:96:5b:01:09:20:
                    cc:01:93:a7:4e:30:b7:53:f7:43:c4:69:00:57:9d:
                    e2:8d:22:dd:87:06:40:00:81:09:ce:ce:1b:83:bf:
                    df:cd:3b:71:46:e2:d6:66:c7:05:b3:76:27:16:8f:
                    7b:9e:1e:95:7d:ee:b7:48:a3:08:da:d6:af:7a:0c:
                    39:06:65:7f:4a:5d:1f:bc:17:f8:ab:be:ee:28:d7:
                    74:7f:7a:78:99:59:85:68:6e:5c:23:32:4b:bf:4e:
                    c0:e8:5a:6d:e3:70:bf:77:10:bf:fc:01:f6:85:d9:
                    a8:44:10:58:32:a9:75:18:d5:d1:a2:be:47:e2:27:
                    6a:f4:9a:33:f8:49:08:60:8b:d4:5f:b4:3a:84:bf:
                    a1:aa:4a:4c:7d:3e:cf:4f:5f:6c:76:5e:a0:4b:37:
                    91:9e:dc:22:e6:6d:ce:14:1a:8e:6a:cb:fe:cd:b3:
                    14:64:17:c7:5b:29:9e:32:bf:f2:ee:fa:d3:0b:42:
                    d4:ab:b7:41:32:da:0c:d4:ef:f8:81:d5:bb:8d:58:
                    3f:b5:1b:e8:49:28:a2:70:da:31:04:dd:f7:b2:16:
                    f2:4c:0a:4e:07:a8:ed:4a:3d:5e:b5:7f:a3:90:c3:
                    af:27
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                03:DE:50:35:56:D1:4C:BB:66:F0:A3:E2:1B:1B:C3:97:B2:3D:D1:55
            X509v3 Authority Key Identifier:
                keyid:03:DE:50:35:56:D1:4C:BB:66:F0:A3:E2:1B:1B:C3:97:B2:3D:D1:55

Signature Algorithm: sha1WithRSAEncryption
         cb:9c:37:aa:48:13:12:0a:fa:dd:44:9c:4f:52:b0:f4:df:ae:
         04:f5:79:79:08:a3:24:18:fc:4b:2b:84:c0:2d:b9:d5:c7:fe:
         f4:c1:1f:58:cb:b8:6d:9c:7a:74:e7:98:29:ab:11:b5:e3:70:
         a0:a1:cd:4c:88:99:93:8c:91:70:e2:ab:0f:1c:be:93:a9:ff:
         63:d5:e4:07:60:d3:a3:bf:9d:5b:09:f1:d5:8e:e3:53:f4:8e:
         63:fa:3f:a7:db:b4:66:df:62:66:d6:d1:6e:41:8d:f2:2d:b5:
         ea:77:4a:9f:9d:58:e2:2b:59:c0:40:23:ed:2d:28:82:45:3e:
         79:54:92:26:98:e0:80:48:a8:37:ef:f0:d6:79:60:16:de:ac:
         e8:0e:cd:6e:ac:44:17:38:2f:49:da:e1:45:3e:2a:b9:36:53:
         cf:3a:50:06:f7:2e:e8:c4:57:49:6c:61:21:18:d5:04:ad:78:
         3c:2c:3a:80:6b:a7:eb:af:15:14:e9:d8:89:c1:b9:38:6c:e2:
         91:6c:8a:ff:64:b9:77:25:57:30:c0:1b:24:a3:e1:dc:e9:df:
         47:7c:b5:b4:24:08:05:30:ec:2d:bd:0b:bf:45:bf:50:b9:a9:
         f3:eb:98:01:12:ad:c8:88:c6:98:34:5f:8d:0a:3c:c6:e9:d5:
         95:95:6d:de

If we access any https website or url whose certificate is not found in operating system or browser CA certificates, it would show below message.

Google and most of the popular search engine and browser providers recommend the service provider to enable TLS/SSL certificate from known CA’s. if they would not get it, then they would de-prioritized in showing there information to the users.

below is the message you might see if the url is not https

What are Different Certificate Types and How to access them from programming language.

The format of the certificate we get from root CA file is base64 encoded X.509, we can use third party tools like openssh to covert X.509 to different formats. There are 2 type of encoded formats PEM encoded, DER encoded.

PEM encoding will have " — BEGIN — and — END — " for each of section like public key, private key and chain of certificates.

on the other hand DER is binary or base64 representation of PEM and mostly the extension of this would be .cer or .ctr

In general, on windows applications we might see DER encoded cer/ctr certificates used. in most of the other places PEM encoded certificate files would be used.

here is a very good explanation of different types of certificates and their usage.

https://support.ssl.com/Knowledgebase/Article/View/19/0/der-vs-crt-vs-cer-vs-pem-certificates-and-how-to-convert-them

On the application side we will have keystore (dont get confused with java keystore/truststore) to manage (add/remove/update) both public/private key pair and digital certificates.

There are 2 main keystores are in use

1. if we are using java application then we would be dealing with JKS keystore
2. if we are using java or other applications we would be dealing with PKCS#12(PFX). unlike JKS, we would be able to extract private keys from PKCS#12

There are two ways TLS/SSL handshake can happens.

1. one way handshake

In this approach server application presents a certificate contains public key with CA or self signature.

Client would check whether the server’s certificate issued is from the known trusted CA to believe that the server application is trust worthy to access and start share information.

2. Two way handshake

In this approach server and client authenticity would be checked

server presents a certificate contains public key with CA or self signature.

Client would also send a self signed or CA issues certificate in return for client’s authenticity to server.

Java way to store and access certificate information

when we are developing client or server application using java, we might come across 2 more terms keystore and truststore for managing certificates in JKS file.

keystore usually used on the server side, holds private and public key used for certificate creation and identifies the organization, and related only public key would be embedded in the certificate which would be shared with the clients.

truststore usually used on client application and holds all the known CA information.

when Server presents certificate contains CA and public key information, client would look for the CA in truststore file on his end and start the conversation if it finds an entry.

we can use "Keystore Explorer" tool or JDK provided "keytool" to view the content in the JKS.

we can also use a KeyStoreUtils java client to view and make changes to the JKS file

sample of new JKS with just certificate + public key using "Keystore Explorer"

JKS file in KeystoreExplorer

The point is if we are using java for client and server side development, we would be need import certificate files to JKS (keystore +truststore) file and set the password. for other languages we would use PKCS#12 keystore for managing the information.

below is sample code to load truststore jks file on client side (one way handshake) to check the authenticity of the server.

import javax.net.ssl.SSLContext;
import org.apache.http.ssl.SSLContextBuilder;

sslContext = SSLContextBuilder.create()
        .loadTrustMaterial(ResourceUtils.getFile(properties.getTrustStore()), properties.getTrustStorePassword())
        .loadKeyMaterial(null, null)
        .setProtocol(properties.getProtocol())
        .build();

Conclusion …

In This blog we understood, what is TLS and SSL. and How the data transferred between client and server.

we understood in detail about Certificate Authority, Self signed certificates and its mechanism.

we also understood different format of certificates used in different programming languages.

GraphQL

When the internet is ruling the world and mobile and web apps are became essential part of our life. The need of high performing, robust applications are required. which comes with redundant functionality being implemented by different applications. can we avoid rebuild same functionality which is well tested and performing well.

can we request the host application for the required information and the service serves the same information if both the party agrees to exchange the information.

RESTFull API is one of the ways to serve this kind of information. Rest API is a light weight Interface to exchange the information between client/clients and server.

REST API will have different API end points to serve each functionality. This is good in 90% of the cases.

lets discuss a requirement to query employee and department details from a service running in a remote server.

we can develop two end points one for getting the employee details ( /employee/{empid} ) and other for department details ( /department/{depid} ).

client can make first REST API call to ( /employee/{empid} ) and parse the response (may be json) to get the department id. and make the second API call to ( /department/{depid} ) by passing department id as @Pathparameters and get the department details. finally client may use just empid and name from the first call, and department id and name from the second response. all good, we got all the information required.

But here There are two potential problems with this approach

• we had to make two REST API call to retrieve all the information we want, though both employee and depart entities has many-to-one relation defined at the database layer.
• Though client just need empid, empname and dept id and dept name. we had to get the complete employee and department information and parse to take just what is require and leave the other data.

Lets get introduced to GraphQL:

GraphQL is a specification to enable query ability on API server to get just what is required for the client.

initially it was developed by Facebook and used as in house application. later on, this was release as a specification so that many languages like javascript, java, python and php can have its's own implementation for the specification.

the advantage of using GraphQL is we can query the related data and retrieve just the fields which client is looking for between the related models. and can avoid hitting the multiple endpoints and shipping over the complete response to client. basically it tries to address 2 basic problems discussed in the REST API.

Note: I have used Django-graphene module to explain the GraphQL. some of the code syntax would be extracted directly from the repository.

some of the main components in GraphQL 

Schema:

GraphQL schema defines the implementation for Query and Mutation for API.

Register GraphQL schema:

class Query(omquery.schema.Query, graphene.ObjectType):
    # This class will inherit from multiple Queries
    # as we begin to add more apps to our project
    pass
class Mutation(omquery.schema.Mutation, graphene.ObjectType):
    pass
schema = graphene.Schema(query=Query, mutation=Mutation)

ObjectType:

This describers Type of the Object we return from GraphQL, every ObjectType will have a name and more importantly all the class attributes will have implicit Fields.

Object Type can be overridden by providing Meta inner-class with model object reference. 

sample of GraphQL ObjectType:

class CellOMType(DjangoObjectType):
    class Meta:
        model = CellOM

Field:

in simplest form GraphQL is all about querying fields from the ObjectType, by default all the members of the ObjectType are mounted to Field.

each Field will have resolve_<FieldName> method attached.

sample of GraphQL Filed:

cellom = graphene.Field(CellOMType, cellid=graphene.Int())
    def resolve_cellom(self, info, **kwargs):
        cellid = kwargs.get('cellid')
        if cellid is not None:
            return CellOM.objects.get(cellid=cellid)

List:

List is used to return multiple ObjectTypes from the resolver

sample of GraphQL List:

all_celloms = graphene.List(CellOMType)
    def resolve_all_celloms(self, info, **kwargs):
        return CellOM.objects.select_related('enb').all()

Queries:

Queries is the GraphQL schema to "query" different Fields available in the ObjectType (Querya fields are highlighted),

Sample code for Query schema:

class Query(graphene.ObjectType):        
    all_celloms = graphene.List(CellOMType)
    def resolve_all_celloms(self, info, **kwargs):
        return CellOM.objects.select_related('enb').all()
    cellom = graphene.Field(CellOMType, cellid=graphene.Int())
    def resolve_cellom(self, info, **kwargs):
        cellid = kwargs.get('cellid')
        if cellid is not None:
            return CellOM.objects.get(cellid=cellid)

Mutations:

Mutation is the GraphQL schema to "update/insert" Model information and persist on database.

Sample code for Mutation schema:

class EnbOMInput(graphene.InputObjectType):
    enbid  = graphene.Int()
    key     = graphene.String()
    om10 = graphene.Float()
    om11 = graphene.Float()
    om12 = graphene.Float()
class CreateEnbOM(graphene.Mutation):
    ok = graphene.Boolean()
    enb = graphene.Field(EnbOMType)
    class Arguments:
        input = EnbOMInput(required=True)         
    @staticmethod
    def mutate(root, info, input=None):
        ok = True
        enb_obj = EnbOM(enb=input.enbid, key=input.key, om10= input.om10, om11= input.om11, om12= input.om12)
        enb_obj.save()
        return CreateEnbOM(ok= ok, enb = enb_obj)
class Mutation(graphene.ObjectType):
    create_enbom = CreateEnbOM.Field()

Relay

Relay is javascript framework built with GraphQL server to enable more interactive query with filters, pagination and mutation for the data.

usually Relay requires one or more "Environment" setup to fire off the requests to GraphQL to perform the necessary actions.

Graphene Django comes with Relay implementation which makes the developer life easy.

sample code snippet:

import graphene.relay as relay
from graphene_django.filter.fields import DjangoFilterConnectionField

class Query(graphene.ObjectType):        
    ##Connect to Relay Node to apply filter filds and pagination
    all_nimsrecs = DjangoFilterConnectionField(NimsTmusType)
 

sample Request and Response:

if we observe the request and response, it has few additional things added.

every Relay field response will have

1. unique node id: this is base64 unique id for each of the record returns from the GraphQL

2. cursor: This is used for pagination through the Relay cached results, cursor will have "first,last,before,after" to select through the result set and limit the number of results from the complete set.

3. pageinfo: This holds the cursor start and end id's to get the complete information of a single page and query the next pages

Request and Response format from GraphQL View:

Django-graphane comes with GraphQL view, which is very helpful for the GraphQL developers to test the API during development.

please refer to the code for GraphQL implementation here

python-Django_graphene