I recently faced a task of creating an OpenSSL certificate, that in turn should be signed by an CA (Certificate Authority). In my case, I were allowed to create my own CA, and thus signing my own certificate.

Here a “quick and dirty” way of creating these certificates..

First, we want to create the CA-key and certificate. We will use these to “sign” our own certificate later. I am in this example using OpenSSH version 0.9.7d-15.13.

cd /etc/ssl
openssl req -new -x509 -keyout private/cakey.pem -out cacert.pem

Now we’ll create a certificate request. This is much what it sounds like. A request for a signed certificate.

openssl req -new -config ./openssl.cnf -nodes -out ./server-req.pem \
-keyout ./server-key.pem

As you can see, this creates an certificate request (server-req.pem) and an key. Now we’ll sign the certificate-request (server-req.pem) with the CA-certificate (cacert.pem).

openssl x509 -req -in server-req.pem -out server-cert.pem \
-signkey server-key.pem -CA cacert.pem -CAkey private/cakey.pem \
-CAcreateserial -days 365

Done! The keys are now signed by your very own (not very trustworthy) CA. These can now be used with for example Apache (when using https) or, as in my case, by any other odd OpenSSL-implementation :)

I’ve been looking for a good way of keeping my Debian-systems up-to-date. However, there are no really good way of doing this, from what I’ve found. There is a problem with letting APT doing both update and installation/upgrade, without having the user to manually intervine. There are no way of the user to know what packages are installed, and if the system needs further configuration or even an restart (if for example the kernel itself is updated/patched).

So, the most practical solution I’ve come up with, is to be informed when updates are available, and then doing the actual upgrade myself. One way of doing this is to use the package cron-apt, which just downloads the new version of the package, but never installs them. It then sends a mail to a predefined user, telling him what packages are ready to be installed.

However, I ended up with writing my own little shell-script. It’s very basic, but does what it’s supposed to.

Update: I’ve made some changes to the script. During the night I was spammed with 19 mails saying that there were updates available, and I only need one mail to tell me that. So, the script no uses a temporary file to find out wether an mail has already has been sent or not. Also, I made som minor adjustments to the code in general.

#/bin/sh
# Debian update script, By G�an Sandahl goran@gsandahl.net http://gsandahl.net
# This script will inform you if there are updated available for your host.
# The script should be kind of self-explanatory. Run it in cron every 10 minutes.

# Set the email-adress that should recieve the update-information. Also, the file
# that contains the last sent mail. When updates are available, a mail is sent only
# if the mail that will be sent isn’t the same as the one in the file. That way
# we won’t get spammed if updates are available, but we are unable to update them.
mail_adress=”goran@gsandahl.net”;
lastsentmail=”/tmp/.lastsentmail.tmp”

# String of how the output is like when there are no updates
matchstring=”0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.”

result=$(echo “This probe was done: `date`” && echo “—” && apt-get update \
&& echo “—” && apt-get –simulate upgrade);

if !(echo “$result” : grep “$matchstring” &> /dev/null) && \
!(grep “$result” cat $lastsentmail &> /dev/null)
then
echo “$result” : mail -s “ `hostname`” $mail_adress
echo “Packages for update, mail sent”
echo “$result” > $lastsentmail
fi

Here’s how the mail looks like: http://gsandahl.net/pictures/debian-update.sh.png

I run this script on all of my Debian-boxes, and they send me an email when updates are available. The mail include the output of both apt-get update and apt-get –simulate upgrade. I recommend placing it in cron, somewhat like this:

twosome# echo “0-59/10 * * * * /home/neewt/debian-update.sh >> /dev/null” >> ~/temp_file
twosome# crontab ~/temp_file

This will run the script every 10 minutes, as the user you entered those commands. I run them as root, because no other user is by default allowed to issue apt-get. However, it might be smarter to give a user sudo-rights (by adding them to the group wheel) and allow them to only run this script with root-permissions. That’s probably how I will do it.

If you don’t have an MTA (Mail Transfer Agent, and is needed for the ‘mail’-command) at the server you intend to run this, I can suggest a tiny MTA. It’s in Debian Stable as the package ssmtp. Very easy to setup, and very easy to maintain.

Please tell me what you think, and/or if you do this another way.

Lately I’ve seen this topic up on the paper several times, in forums, mailinglists and on blogs. This weeks column at http://www.securityfocus.com discusses this topic, and it does this from a (for me) new perspective.

An security-implementation is only as strong as it’s weekest point. Might sound like a klich� but it’s more like a fact. It’s argued wether a closed-source security-implementation in any way can claim to be secure, when the implementation it self cannot be reviewed. If we take the VoIP-protocol/program Skype as an example. Skype’s ”tecnical FAQ” states that: Skype uses 1536 to 2048 bit RSA to negotiate symmetric AES keys.. This actually sounds fantastic, they are using the latest crypto-technology, it must be the safest solution ever. However, we have no way of knowing how the ”negotiation” is done, and how keys are stored. The implementation itself can break the security that AES and RSA offers. Skype is not alone with saying that they ”offer full privacy and secrecy”, but how can we know that the implementation is secure? If we instead look at Jabber, which is a open-source IM-protocol (Instant Message Protocol), the implementation of SSL (Secure Sockets Layer) can be fully reviewed and therefor offers the ability to full security. That is, if the implementation turns out to be secure.

Some say that without the ability to review the implementation of cryptography, security cannot be offered at all. It’s then just based on trust. Trust of the implementers, like the folks behind Skype. I stand by this argument, but am also aware of the risks of being to ”paranoid” when thinking this way. Because, when thinking like this, practicly no propitery software is secure. I, some time ago, saw a comparison with cars and its security-implementations (like airbags and abs-brakes). These are reviewed by undependent organisations, and it’s done like this because it isn’t enough that the car-manufacturers states that: ”we uses the latest technology and material on our airbags”.The statement itself doesn’t guarantee any security. The airbag could in fact kill you, if implemented wrongly. Why should there be any difference in digital security?

The article I mentioned above (securityfocus’s this weeks column), discusses security-implementations in hardware. Take an WAP (Wireless Access Point) as an example. Many of them offers WEP, WPA or and Mac-adress-filtering. Sounds good (or, no it doesn’t!), but we know nothing of how it’s implemented in the Acess-Point. And we have no possibility what so ever to review it. Will there be a trend in the future where companys like 3com and Cisco will release their firmware as open-source? Ironicly enough, Cisco’s security is most certanly more reviewed than other companys firmware. (Because of the IOS-source-code where stolen last year). Funny enough, I don’t know wether this talks fore or against Cisco :)

Couldn’t companys working with closed source, realease the code of their implementation free. Or at least have a independent organisation reviewing it? If the implementation itself is their ”product” (like sofware offering encryption of files and partitions), this can be troublesome. However, for now, if someone asks me, ”is this product secure”, I’ll think again before answering. AES and Twofish in all their glory, but without any knowledge of their implementation, they guarantee nothing..

404 - Page not found

Sorry, the page you are looking for are no longer placed on this URL. Please use the searchbar to the right to find the document you are looking for. Sorry for this inconvinience..

/Göran