The Awesomeness of Open Source

A few days ago we made the decision to change the default insecure HTTP protocol being used in our company website: Protean Security with a secure HTTPS protocol. The process was very easy at the beginning and there was little needed to be configured. Basically we had to register our own SSL certificate signed by a trusted CA (certificate authority), we had to change a few settings in our web server and a few other minor things. Up to now, everything went smoothly and we've realized that the switch didn't take more than an hour. But after initial testing, we soon realized the problem couldn't be solved just as easily.

A few days ago we published an article about Cuckoo Malware Analysis that was well received in the community, which can be verified by looking at the the statistics presented by the Wordpress plugin Juiz Social Post Sharer. We use that plugin to allow the visitors of the blog to easily share the content easily, plus it fits nicely with the wholesome design of the website. The statistics of the Cuckoo article can be seen below, where the article has been published 589 times on Twitter alone.


The statistics above are presented quite nicely when viewed over an unencrypted HTTP connection, but when viewed over an encrypted HTTPS connection some resources failed to load. The picture below shows the statistics when connecting to the website over encrypted HTTPS connection – there are no statistics about shared article, but the real question is why does that happen?


The URL in the Chrome web browser shows a shield icon next to the URI and if we click on it, a pop-up will open asking us whether we would like to load unsafe script?


If we right-click on the website and select 'Inspect element' and go to the Console tab, we'll quickly realize that we're trying to load an insecure HTTP content over secure HTTPS connection we already have established. Since that is not secure, the web browser itself is blocking the connection not letting the appropriate scripts get executed in order to retrieve the statistics about the number of article shares on different social networks.

Implementing our own solution

After realizing what the problem is, we didn't want to switch to another social sharing plugin, because the current one works best in our case and the design fits into the website quite well. Therefore, we decided that we'll take an open source plugin and change it to fit our needs and make it work over the encrypted HTTPS connection.

First we cloned the repository from Github:

# git clone

After that we started changing the code. The code below shows a few of the URLs used to get access to the number counts, but they are all done over insecure HTTP connections, which is the primary reason for our problems.


After changing all the links from HTTP to HTTPS, part of the problem went away. The result is shown below, where only the Linkedin counter works as expected, but the others do not.


In order to figure out what the problem is we've looked at the plugin code and identified how the plugin identifies the counters. In order to obtain the number of shares on Twitter, we have to send the following request to the Twitter API server. Notice that the url GET parameter takes the address of the website for which we want to obtain the counter?


The response is shown below, where the API server replied that the blog post hasn't yet been shared. But it's supposed to be shared 589 times, why is the server reporting 0?


The answer lies in the fact that the servers differentiates between the blog posts using http:// or https://, which are treated as a separate blog posts. The picture below presents the same request as before, but the https:// prefix was changed into http:// prefix.


The response presented below clearly shows that now the server API reported the right number of shares.


By changing the protocols being used in the URL from http:// to https://, we're effectively throwing away any statistics that were already gathered. Therefore, we need to add an additional functionality in the plugin, which will sent two requests to the API servers, one for the http:// and the other for the https:// and report both values back in statistics.

We've done that by changing the js/juiz-social-post-sharer.js core plugin code. Basically we've added a separate function that accepts the type of API URL we would like to get back. The funtion also accepts the url for which we would like to obtain the counter statistics.


The function juiz_formurl is called by every enabled counter API that we would like to obtain. The basic code block looks like presented below, where we've initialized a counter by assigning a zero value to it. Then we've sent two JSON GET requests one for the http:// and the other for the https:// website URLs. The results are added together and displayed in a website.


In order to install the new and improved social sharing plugin, all you have to do is clone the repository from our Github account.

# cd wp-content/plugins/
# git clone
# chown www-data:www-data juiz-social-post-sharer -R

And then enable the plugin in the wp-admin web interface.


In this article we've presented how we can solve the problem in an open-source software by simply changing the code in order to fit our needs. We've shown how we ported our website from insecure HTTP protocol to a secure HTTPS protocol and the difficulties that we've stumbled upon in the process.

Whenever you're dealing with an open-source solution, you can take the source code and change it accordingly to your needs. At such time you have to invest some time to actually write the code in order to solve the problem. After you're done experimenting with the code, you can share it with the world and make it available to anyone who stumbles upon the same problems.

I hope you have enjoyed the article of taking an open-source software and changing it to your needs. If you have done something similar in the past, I urge you to share your endeavours in the comments below.