SSL Part 3 – HTTPS – Communication Type

In Part 1 we cover the basic of SSL, PKI. CA. In Part 2 we covered truststore and identitystore. I classify the HTTPS – SSL communication in 2 sub types.

1. 1 way SSL

2. 2 way SSL

They are not 2 types but i call them as such. The protocol wise there are minor variations but from setup perspective there is lot of difference between 2.

 


1 Way SSL

This most commonly used for consumer to business communication. When I launch my bank’s website to login into my account, it is 1 way SSL.

In this case we (the client) wants to validate the server’s certificate, to make sure it talking to right server \ entity. The server verifies the client’s identity using username and password.

In this case, client will have to add server certificate or signing CA (CA that singed server’s certificate)  to its truststore. In case of banking example, most bank has cert signed by well known CAs, and certificate for these CAs are already in the browser. 


2 way SSL 

This mostly used for server to server communication. 

In case, let say entity 1 is server and entity 2 is client. So when client entity 2 connects to server entity 1, it will provide it’s certificate to client, but also ask \ challenge client to provide its certificate. So client certificate instead of username \ password is use to authenticate client identity. So in case client also has to have certificate for itself.

So client will have to include server’s certificate or singing CA in its truststore. Similar server will need to have client’s certificate or signing CA in its truststore.


So when debugging SSL issue you need to first understand whether you communication is 1 way ssl or 2 way ssl. Based on sub type right certificate are in right keystore file.

If i have customer facing website i cannot expect everyone to have certificate generated by verisign to validate their identities, i would use 1 way SSL there. If its back end service i can use using user name \password or 2 way SSL for authenticating client identity.

SSL Part 2 – HTTPS – What is java truststore and identity store

In Part 1 we covered the basics of SSL, PKI. CA. Before we move to Part 3, it is important to understand the difference between trust store and identity store. This discussion is kind of specific how SSL works in Java. From little background in .NET this is identical but term could be little different.

In Java certificate are stored in file called Java Key Store (JKS) file. This has extend .jks. I am using Keystore Explorer utility to show you the internal of jks file, you can keytool that comes with java, but it outputs in text and hard to visualize.


Trust Store 

This jks stores all public certificate of all the entities that we trust. In java, under jdk or jre install you will find trust store to be located at \lib\security\cacerts (this jks file even though it does not have extension). The default password for it is “changeit”. It will ask for this when you try to open it. 

 part 1 pic 1

 


Identity Store 

Some call this keystore. This is jks file that store my entity’s public certificate along with private key.  This file does not come with java out of box. (You can either create one using keytool or you can use keystore explorer). Typically you will have 1 or in some cases handful of entries in this file.

part 1 pic 2

 As you will see in this snapshot, this enter looks different that other enters in truststore. Trust store has all entries with symbol of certificate besides it, in identity store beside you will pair of key, and lock. The keypair indicate that this has both private and public key, lock symbol indicates the private key is locked using passphrase.

SSL Part 1 – Basic of SSL, PKI and HTTPS

This is very basic. This will help in case you are just starting with SSL. I have kept things simple to make it easy to understand. For folks seeking more in depth details,  i will cover each area in more details in follow up blogs.

 

SSL \ TLS  is protocol to communicate securely between 2 system\computers. It works at transport layer. The 2 system can be client to server, server to server. SSL use PKI – public key infrastructure.

PKI uses concept of private key and public key. As name suggest – private key is private and kept securely with entity (can be either server or client) it belongs to. Let call this entity 1. Entity 1 will distribute its public key to everyone. Private key and public key are unique pair, complex mathematical algorithm is used to generate the pair. So its impossible to reverse engineer private key from public key.

If you encrypt message using public key, it can only be decrypted with private key and vice versa.

So when entity 2 wants to send secure message to entity 1. Entity 2 uses entity 1’s public key (which is publicly available) to encrypt message. So only entity 1 which has private key can decrypt the message.

Conversely, entity 1 can sign message with its private key so that when entity 2 received it use entity 1’s public key to valid the message is indeed coming from entity 1.

So this simple.

 

 

But there is loop hole in this, public key are exchanged on internet. Communication between 2 systems passes through lot of intermediate entities (router, other servers), so how do know for sure that public of entity 1 is true entity 1’s public key. There would intermediate entity 3 which can represent itself to be entity 1, and provide it public key as entity 1’s public key. This man in the middle (MITM) attach. (more detailed explanation is at http://en.wikipedia.org/wiki/Man-in-the-middle_attack)

So we require neutral 3 party entity that can be trusted on the internet. Those entities are called Certificate Authority (CA). Verisign, Geotrust, Comodo etc are some of CA out there. We understand CA, which try to resolve MITM issue.

All CAs have cert publicly available and distributed with installation of software. There is list of CA already included in all browsers, Java installations. If you are interest you can google to find how to look at CAs in our browser and java. This is called as trust store, so store of all the Cert Authorities that software or entity trusts.

So what difference between Cert and Public key? In simple term certificate is nothing but entity’s public key which is signed by CA and has some additional information regarding usage of that certificate. Certificate has information as to which CA signed it and CA’s own public certificate or key. It also has information when certificate was issued and till when its validate.

 

 

So now coming back to MTIM attack. So instead of distributing public key, we take entity 1’s public key sent to CA like Verisign to get public certificate. And distribute that public certificate instead of public key. So Verisign is vouching that this is public certificate belonging only to entity 1.

So when entity 2 receives entity 1’s public certificate it does following

1. Get the entity’s CA from certificate.

2. Validate if that CA is present in Trust Store.

3. Validate if certificate is valid (not expired etc, there are few more things it will check but not going into details at this point).

If the presented certificate is valid, it initiate the communication.

In case MITM attack is avoided because CA will never (almost likely) issue certificate to entity 3 saying ti entity 1.

 

 Https is nothing but http protocl that use SSL protocol to secure http communication between 2 system.