January 2010 Archives

After having installed an open source online-shop software on a VPS I had to suffer a hefty delay following the login as administrator until eventually the control panel appeared on the screen. Despite of this admin login problem the software ran fast and responsive, but the admin login, which would normally only take 2 seconds, took more than two minutes to complete.

Possible causes for this problem are manifold, some misplaced configuration option, a software bug, a missing software component, many things are conceivable. What raised my suspicion was the fact that this problem seems to occur only at the administrator login, well, I hadn't created new users by now. It is likely that the problem occurs for new users as well.

The Hunt

Actually there were two separate delays that cropped up after I typed the admin password, with a little bit of activity in between. It looked like a time-out, so I shut down the VPN's firewall and the problem was gone. At this point it was clear that some network activity took place which normally was blocked by the firewall. To find out what was going on I engaged a wonderful network analysing tool called wireshark or tshark to capture the network packets after login. It turned out that the VPN initiated a http and a second https connection to a server within the domain of the online-shop's original vendor.

I know it's only me who tends to think of a possible backdoor, a software "calling home" to report something, in such a case. But at this point I wanted to find out what was going on behind the scenes. Out of sheer curiosity I started to poke into the source code to find more informative evidence. As you may imagine, looking for "http" in the source code revealed tons of references that were mostly inactive links to the vendor's homepage. More extensive filtering brought a function "load_xml_file" to light that was used to download a file that contained only innocent version information in XML format that could as well be part of the distribution and stored locally.

Benefits of Open Source

The vendor had decided to download this file to make sure that the online-shop software will automatically become aware of a new version once it is released. Of course this is a legitimate intention, but it would force the shop user to open outgoing connections on the server machine to avoid the timeout penalty which could open up another can of worms for other applications. I decided to change the source code to load the information from local files instead of the vendor's homepage and turned on my restrictive firewall again.

This is exactly the flexibility and reliability one gets with using open source software which would never, ever be possible if you used proprietary solutions instead. People often say, nobody looks at the source code, which is true for many open source programs, but with proprietary products you would not even have the chance to take the approach described above, because you are at the vendor's mercy to accept what the program is actually doing.

The freedom to change the code is a benefit that could possibly not be overestimated.

On the last day of the year my email stopped coming in. You may have read about my approach to fetch my email using a secure tunnel that uses SSL certificates in addition to a password to access my email. Well, on the last day of the year my ROOT CERTIFICATE, which I use for Kerry Linux, had expired after five years. Time flies by.

As I had other plans for the days ahead I thought just to renew the root certificate to buy time, but it seemed that my attempts to renew my root certificate did not result in a new usable certificate to replace the old one. My user certs, which are not up for expiration yet could not be reanimated with a quick fix like that.

After a while I thought, there is a reason for that and I began to think about root certificates more thoroughly. In the past five years we've definitively seen the crackdown of MD5 and SHA-1 is not invincible, too. Would it not be prudent to increase the key length and to use a more secure (i.e longer) hash and go through the trouble of creating a new root key and issue new user certs? I decided to go along that route and created a fresh new CA root key with 4096 bits for the Kerry Linux Certification Center. Although my openssl software does only permit using SHA-1, which is a pity, I felt content and everything was up and running for me in an hour or so.

Re-Animation of the old ROOT KEY

After a while I began to wonder if it was possible to reanimate the old key and out of curiosity tried to explore the way to do it in more detail. I googled and found this nice posting from Arsen Hayrapetyan which led me to success. My former attempts to recreate the old certificate always led me to the following error message when I tried to verify a user's certificate::

Unable to get the issuer certificate? I supplied it in the command, but it didn't work out as planned.

So I followed Arsen's hints and created a testbed for an experiment, where I set the serial number back to 00 and emptied the file "index.txt" so that my new certificate could inherit the properties of the old one including its serial number. Then I created a new certificate request based on the old root certificate "cacert.cert" and used this new request to sign it with the old key.

The result was a new root certificate "cacert_renewed.pem" that verified my old user certs perfectly.

It's good to have an alternative, isn't it?