SSL/TLS : An introduction to security

SSL- Secure Socket Layer is a security protocol between the two communicating applications. In this post, we will focus on the questions.

  1. What is SSL?
  2. Why use it?
  3. How does it work?

What is SSL?

If you go by the SSL RFC6101, “The primary goal of the SSL protocol is to provide privacy and reliability between two communicating applications”. So in simple words, SSL is the Security agreement between the two parties in communication.

Here is an Example, where you can see SSL working:

Capture_SSL1

Here you can see that the standard http is replaced by https, plus you can see a Lock symbol. 

The https in the URL tells Browser that the connection between the client(Browser) and Server(Here it is youtube) must be secured using SSL.

The Lock symbol is called the padlock. It means the connection is secure with SSL. If you don’t find the padlock, it means that the page doesn’t use SSL.

Why use it ?

Security is a major concern in today’s world. Since our data is sent to the outer world through so many untrusted networks, we need a way to secure it. SSL protocol provides us exactly what we need. It sets certain guidelines for the encryption protocols to be used, what keys need to be used for the encryption/decryption and some other agreements regarding the communication. A detailed description of how SSL protocol works will be in the future post(s).

How does it work ?

We use SSL in the form of SSL certificates. The certificates are exchanged between the two communicating parties. Most common scenarios are while accessing a website, bank transactions etc. Either one or both the parties install the SSL certificate. After installation of the certificate, one of the party initiates the connection and both exchange their certificates, which are validated against the trusted store of the receiving party. After certificate validation, the other guidelines and agreements are made between the two parties. Once the agreement is set, the two parties start exchanging the data. After the exchange of data is over, the connection is closed.

So this is What, Why and How of SSL.

In next post, I’ll be going over more details of SSL.

Cometd Compatibility with Jetty

Recently, I was performing a load test on Cometd and Jetty together. The Cometd had a version 1.0.0(too old, not even maintained now) and Jetty version 8.1.11. I found that my Jetty was going out of memory, its heap memory allocated for the process was full. So the notifications started failing.

First, I analyzed the jetty logs and found that logs were full with Timeout Exceptions in between the notifications. Timeout exceptions were like

WARN:oejut.Timeout:EXCEPTION java.lang.NoSuchMethodError: org.eclipse.jetty.util.LazyList.removeFromArray([Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; at org.cometd.server.ClientImpl.removeSubscription(ClientImpl.java:495) at org.cometd.server.ChannelImpl.unsubscribe(ChannelImpl.java:339) at org.cometd.server.ClientImpl.unsubscribeAll(ClientImpl.java:527) at org.cometd.server.AbstractBayeux.removeClient(AbstractBayeux.java:526) at org.cometd.server.ClientImpl.remove(ClientImpl.java:370) at org.cometd.server.continuation.ContinuationClient.remove(ContinuationClient.java:220) at org.cometd.server.continuation.ContinuationClient$1.expired(ContinuationClient.java:60) at org.eclipse.jetty.util.thread.Timeout.tick(Timeout.java:140) at org.eclipse.jetty.util.thread.Timeout.tick(Timeout.java:153) at org.cometd.server.continuation.ContinuationBayeux$1.run(ContinuationBayeux.java:76) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462)

Now this was the time to take the heap dump and analyze it to find who is the real culprit. The following command helped me in taking the heap dump.

jmap -F -dump:File=heapDump <jetty-pid>

You can also run the following command to check the instances of each and every object.

jmap -F -histo <jetty-pid>

Now I analyzed the heap dump using Java VisualVM(). I found following classes had the maximum number of instances(almost 2.3 million).

org.eclipse.jetty.util.ArrayQueue

org.cometd.server.ChannelImpl[]

org.cometd.server.continuation.ContinuationClient

org.cometd.server.continuation.ContinuationClient$1

org.cometd.server.continuation.ContinuationClient$2

Now it was time to check the code, but before that, I also found the number of instances of the ContinuationClient, ContinuationClient$1, ContinuationClient$2 was equal to the number of Timeout exceptions that had occurred. So from the heap dump and the logs, it was quite clear that the removeFromArray method is not functioning properly due to which the instances were not getting cleaned up.

On checking the code, I was unable to find any issue, so I thought of upgrading the cometd to a version which supports Jetty 8.1.11. So, I searched it on the web and put a question on SO. The answers to the question were quite clear and helped me to find where the issue lies.

from the answers, it seems like the best way to find cometd version compatibility with jetty version is to check the pom.xml of specified version of cometd.

For example, the cometd 2.6 pom.xml says it is built with jetty version 7.6.10.v20130312 , while the cometd 2.7 pom.xml says it is built with jetty version 7.6.13.v20130916 and 8.1.13.v20130916.

So now the solution to my problem seems to be both jetty and cometd latest upgrade.

VALGRIND: Memory Saviour

Sometimes we code and get segmentation fault all thanks to the mismanagement of the memory done in your code.

We allocate memory using malloc() and forget to free it. this also causes the leakage of memory.

There are times when we unknowingly free a memory location twice.

When our code is large, have thousands of lines of code , it becomes difficult to find out the memory leakage. So the saviour is Valgrind a tool which checks the memory leakage, and null pointer references and many other memory issues.

Usage of Valgrind :

First, we need to compile the program with –g option, -g enables the use of extra debugging information.

gcc -o test -g test.c

After successful compilation, we can check the memory leakage using the memcheck option.

valgrind --tool=memcheck --leak-check=yes --show-reachable=yes

You will get Summary of errors in the end after the check for leakages as Leak Summary

Leak Summary will tell you more about Definitely lost memory, Possibly lost memory, Still Reachable memory and Suppressed memory.

You can learn more about the Valgrind errors here .

My First Post

First Post remains the first. It reflects the personality of the person. Set the criteria of the blog. No doubt my posts will be about some geeky stuff about computer and also some algorithmic concepts some programming stuff i was involved in and some queries and interesting questions