Client authentication - SSL Handshake

Client authentication is an optional step in SSL Handshake.

If client authentication is requested, then after verifying Server certificate, Client sends "Client Certificate" along with the encrypted pre-master secret ( encrypted using public key from Server Certificate).

One more info is send by client along with this request. Client encrypts a "data" which is known to both Client and Server using Client's private key. When Server receives the request it can validate the public key of client by decrypting this.

Then Server proceeds further by authenticating the Client Certificate. This is done as follows:
1. validity (expiration date) of client certificate is checked.
2. Is the issuing authority of the certificate is a trusted CA by Server. If not.., Server checks whether any CA in the certificate chain of the client certificate is among the trusted CA of server.
3. Then it validates the integrity of the certificate. This is done by hashing the Certificate Message and comparing it with the hash obtained by decrypting the digital signature by CA's public key. Both should be same.

The Client is now authenticated. Now it can check for the resources which client is authorised to access by checking the ACL ( access control lists).

SSL - Secure Sockets Layer

As a part of study, wanted to dig into one protocol which uses Certificates for hanshake. Selected SSL. SSL works above transport layer. Protocols like HTTPS uses HTTP over SSL for secure communications. VPNs like OpenVPN also uses SSL as the underlying protocol.

SSL uses
stage 1. Assymetric encrption for intial handshake - authentication and privacy
stage 2. and later moves to faster symmetric encryption for further communication using the Master Key generated during the first stage.

Brief Idea on how the protocol works is:
1. Client sends HELLO to Server ( and details like Cipher suites, session data etc)
2. Server sends back ACK ( Session specific data and Cipher Suites and SERVER CERTIFICATE)

3. Now Client verifies the Server Certificate... Only if it is ok the client proceeds further.

4. Now client sends data encrypted by Server's PUBLIC Key. Client sends the pre-master secret key to the Server.

5. Now the mystery part ( Its still a mystery to me). Client and Server uses the pre-master secret to generate a master secret. Using Master Secret Client and Server generates Session Keys...

6. Now Client sends an encrypted message to Server saying that hanshake is completed. Server also sends a similar message to the client..

7. Now on all data between client and server is encrypted by the session keys..

In the default mode, only Server is authenticated. But Client side certification can also be given. In this case, client will also send its certificate in the step 4 mentioned and Server verifies it.

Assymetric algorithms used are : RSA, Diffie Hellman
Symmetric Ciphers: Triple DES, RC4, RC2, DES

Contents of a Digital Certificate

I was trying to study what all info a digital certificate contains.. I decided to look at the site I freqeuently visit for buying movie tickets - Sathyam Cinemas.

The Certificate shows it was issued by Verisign. It is issued to "tickets.sathyamcinemas.com. But the name of their site is "thecinema.in". So it gives some warnings to the user.



I went to look at the contents. It says in detail - Issuer, Issued to, Validity Period, Algorithm used etc etc. Also we can see that the "Public Key" of Sathyam Cinemas is send along with the Certificate.

Further Details:

The certificate chain shown here. Who is the signing authority of the certificate can be seen here

The digital certificate will contain the digital certificate. It is the encrypted hashed value of the message. It is encrypted using Issuing Authority's private key.

Usage of Digital signature

I would like to refine the "case example" i said in previous post.

There are cases where the full privacy of message is important that we have to fully encrypt the message.

In some other scenarious the importance will be on several other factors. say;
1. Authentication
2. Non-repudiation
3. Integrity

Authentication: When Anoop sends a message to Biju. Biju should be able to verify that it is send by Anoop. He can do that by decrypting with Anoop's public key.

Non-repudiation: Nobody has Anoop's private key. So there will be no chance that anybody else will use Anoop's private key. So Anoop cannot deny that he has not send the message.

Integrity: The integrity of the message has to be validated. If somebody alters the message in between, the recepient should be able to detect it.
This is done by using digital signature: what it does is -> The sender will take the message contents, and will hash the message. This message will be encrypted by issuing authority's private key. The encrypted hash message is called digital signature.
On Receiving side: The recepient will take the message and hash it. Also he will take the encrypted hash and decrypt it with issuing authority's public key. The two hashes obtained can be compared and if same the message is ok for "integrity"

!!!
Disclaimer: Hi.., my readers. Better will be to read wikipedia. I am still learning the concepts!

Public key cryptography

Usually we close our doors with a key and then we can open that back only with the same key...

In Public key cryptography there are two keys - key1 and key2. If we close with key1, then we can open only with key2. And if we close with key2, we can open with only key1. Nice assymetry!

One key we dont disclose and keep it as secret - its Private key as name denotes, other key we can give to Public, and hence named Public key..

Some examples where i can use:
case1: say i want to send a mail to biju and i want only Biju to read that mail. So i can encrypt with Biju's public key and send. Only Biju will be able to decrypt the message (with his privatekey).

case2: in another case, i want to send a message, but i want Biju to be sure that its me who has send this message. Then i can encrypt with my private key. Biju will be able to properly decrypt that only(with my Public key).

So Biju and me are happy!