My everyday job is to find solutions to optimize systems that are working but that could also be better / faster / cheaper. Today, we’ll look on how to optimize your SSL / HTTPS layer for your webserver.

The problem :

The problem is that we want our webserver to provide a secure channel to our clients and to be as fast as possible to deliver all of our content. But the SSL layer usually adds up a large overhead to any http request, simply because data needs to be encrypted or decrypted (depending if we send or receive data ).

In a world where we CPU performances were increasing all the time, we could simply invest on a new, better performing, server hardware. It would be a bit pricy but would do the trick for a while. Unfortunately, that would really help you to scale much. You could also invest on a dedicated SSL hardware appliance but since that would cost you an arm and we need that arm to type on the keyboard, I digress, we would prefer something a bit smarter.

So, what’s the solution ?

The solution is simply to understand what is SSL. SSL is a suit of ciphers. All ciphers are mathematic formulas in a package that helps you to use them. But some ciphers are less ressource-consuming than others, some are dedicated to streams and others are not.

When you configure your webserver, you generally enter the following line:

SSLCipherSuite HIGH:+MEDIUM:+LOW

This tells you webserver  that it supports:

• ALL HIGH security ciphers,
• ALL Medium,
• ALL Low

You web-browser will then pick on in the list (generally the most secure) and start to use it. Unfortunately, this means that you will end up using AES256 which is VERY resource consuming.

How can I tell my webserver to use which cipher ?

Well, for Apache, you just have to enter the following line :

SSLCipherSuite RC4+RSA:HIGH:+MEDIUM:+LOW

This will force your webserver to present at first the RC4 protocol and not our AES256 friend. In case of a browser who wouldn’t understand RC4, you can always fallback to AES256 and back all the medium and low ciphers.

In case, you would have doubt about the security provided by RC4 ( after all, the protocol has been used in WEP ), you should be convinced that a proper implementation of RC4 is very secure even with a 128bits long key.

3 … 2 … 1 … GO !

Comparing AES256 and RC4 (using a 128 bit key) wouldn’t be fair. Let’s compare what is comparable : AES128 and RC4( using a 128bit key).

SSLCipherSuite AES128+RSA:HIGH:+MEDIUM:+LOW

and

SSLCipherSuite RC4+RSA:HIGH:+MEDIUM:+LOW

Conclusion

You can see, that you have a nice performance boost for the price of 0.00$/€. Isn’t life great ?

Hi everyone,

It’s been a while since I haven’t post anything here. Well, the truth is I have been pretty busy with some projects. And I’ve been able to play with a Buffalo TeraStation Duo with 2x512GB.

But let’s dig in what we are here for, Debian Install.

A bit of specs :

• cpu : Arm9 at 800Mhz
• memory : 512MB
• Flash : 512MB
• Net : 2 Ethernet ports.

Hey ! But why the hell do you want Debian on it ??? It’s already pretty smooth and neat !
First, it’s funny, secondly, I learnt a lot by doing that and third .. well … if Buffalo Administration software
does enough for your needs, why are you reading this ??? Hmmmm ?

Well, enough ! Let’s go.

How does the buffalo works ?

The NAS use u-boot bootloader to boot. u-boot is a pretty well documented bootloader and is able to boot nearly everything.

In the normal case (99% of the time), it boots from the RAID1 array and load the kernel (and an initrd image).
In a non-normal case (the so infamous 1% – for exemple, in case of a hard disk crash), it boots another kernel (and initrd image) from the NAND device. This mode is pretty useful when you have screwed up your NAS.

If I was rich and patient, I’d bought a serial cable with a usb-serial converter to use the serial plug located in front of the device
but I am fairly poor at the moment and really excited to play with the baby.
We would have put the initrd from debian-installer and enjoy seeing the installation going smoothly.

But no, I am poor… and hopefully, we’ll find another way.

A bit of theory : How does Debian Lenny netboot works ?

Well, pretty easy. The installation disc load a kernel together with an initrd image. This initrd has a script and launch some required scripts that setup everything and finally launch debian-installer. debian-installer will then guide you through the complete process of a clean and neat debian installation.

Here is the summary of what we will do:

• Gain shell access to you TeraStation Duo
• Backup the actual kernel and initrd image
• Modify the initrd image to make sure that we will boot correctly
• Package the Debian Installer for an easy use
• Upload the necessary files
• Screwup your nas to make it start in EM mode
• Gaining access to your NAS (in EM mode)
• Prepare the chroot environment and launch the debian-installer
• a dirty Hack !
• Install DEBIAN (YEAH !)
• restore the kernel and initrd
• install the WatchDog monitor
• rebooting (and praying !)

Gaining access to you NAS:

Some (very) nice people have seen an security hole in Buffalo ACP protocol and have made a tool to exploit and thus, gain access to your NAS by resetting the root password and starting a telnet deamon.

You can find acp_commander by clicking on the link. And because you all want to gain shell access to your NAS, here is the command to use :

java -jar acp_commander.jar -t <ip_of_your_nas> -o

This should launch a telnet.

If this doesn’t work, the try the following:

java -jar acp_commander.jar -t <ip_of_your_nas> -ip <ip_of_your_nas> -pw  -o

You can now connect by issuing the following command:

telnet <ip_of_your_nas>

Backup the actual kernel and initrd image

Now that we are in, we have many possibilities. You could install the OPTWARE packages and live the rest of your life happy and in peace, or we can go further and install a Debian system. Let’s backup the kernel and the initrd image as this tutorial covers the Debian Installation but not the installation of a custom kernel.

$> scp /boot/uImage.buffalo <someone>@<somewhere>:
$> scp /boot/initrd.buffalo <someone>@<somewhere>:

Modify the initrd image to make sure that we will boot correctly

The initrd that we have just backed up, will be used when we will boot our new Debian. But if we use it has it is, the scripts contained in the image will probably do a lot of annoying things (like populating a /etc for no reason, saving the configuration, checking the filesystem). We don’t want that. So we use the technique described here ( How to modify an initrd ) to modify the linuxrc script.

HddRoot()
{
    echo "-HddRoot-"
    if [ "${SUPPORT_RAID}" = on ] ; then
    AssembleSysMd boot
    fi
    fsck_disks
#    HasUpdatedFile
#    if [ $? != 0 ]; then
#        echo "** has Updated Files **"
#        echo "** Creating system hotadd pending flag **"
#        touch /tmp/need_firmup
#        echo "0x100" >/proc/sys/kernel/real-root-dev
#        return
#    fi
    if [ "${SUPPORT_RAID}" = on ] ; then
    AssembleSysMd
    fi
#    TestRootfs
#    if [ $? != 0 ]; then
#        echo "0x100" > /proc/sys/kernel/real-root-dev
#    else
    if [ "${SUPPORT_RAID}" = on ] ; then
    echo "0x901" > /proc/sys/kernel/real-root-dev
    else
    echo "0x802" > /proc/sys/kernel/real-root-dev
    fi
    IS_HDDROOT=1
#    fi
}

Note : 0×901 represent /dev/md1 … the partition that contain the real-root…

$> umount INITRD
$> rmdir INITRD
$> mv initrd.buffalo initrd.stock [backup just in case]
$> gzip initrd
$> mkimage -A arm -O linux -T ramdisk -C gzip -a 0x0 -e 0x0 -n initrd -d initrd.gz initrd.buffalo

Package the Debian Installer for an easy use

Now, we want to launch the debian-installer but … we have booted in EM mode which mean that we have booted with Buffalo’s initrd. Fortunately, Debian always do things the right way. Let’s get the Debian-Installer package, extract it and put in in a tar.gz file that we will be able to extract once booted in EM mode.

$> wget http://ftp.debian.org/dists/lenny/main/installer-armel/current/images/versatile/netboot/initrd.gz
$> gunzip initrd.gz
$> mkdir deb_init
$> cd deb_init
$> cpio -i < ../initrd
$> tar cf ../deb_init.tar *

Now we can upload that new archive file on the NAS.

$> scp <someone>@<somewhere>:/sompath/deb_init.tar /boot

Screwup your nas to make it start in EM mode

u-boot will fall back into booting the EM mode in case  of three unsucessful boot of the normal mode. Let’s now make sure that the NAS will never boot again

$> rm /sbin/init

now it’s time to REBOOT !

Gaining access to your NAS (in EM mode)

After three failed reboots, the NAS will enter the EM mode.

Same procedure :

java -jar acp_commander.jar -t <ip_of_your_nas> -o

Preparing the chroot environment and launching the debian installer

To be able to install Debian, we have to make a bit of preparation

$> miconapl -a system_set_watchdog 0
$> killall daemonwatch
$> killall miconmon clientUtil_server kernelmon errormon cat

# if /boot is not mounted yet
$> mdadm -A /dev/md0 /dev/sda1 /dev/sdb1
$> mount /dev/md0 /boot
$> mkdir /debian
$> mount -t tmpfs tmpfs /debian
$> cd /debian
$> cp /boot/uImage.buffalo /boot/new.initrd.buffalo /debian
$> mv /debian/new.initrd.buffalo /debian/initrd.buffalo
$> tar xf /boot/deb_init.tar
$> mount -t proc proc proc/
$> mount -t sysfs sysfs sys/
$> cp /boot/uImage.buffalo initrd.buffalo /debian
$> umount /boot
$> mdadm -S /dev/md0
$> chroot .

$> /lib/debian-installer/start-udev
$> sh /lib/debian-installer-startup.d/S01mount
$> sh /lib/debian-installer-startup.d/S10syslog
$> sh /lib/debian-installer-startup.d/S15lowmem
$> sh /lib/debian-installer-startup.d/S20templates

a dirty Hack !

Here is an awful hack. If you attend to kill dhcpcd to make sure that the debian installer will not get confused, then it will shutdown your interface and you will lose your telnet session. If you kill -9 dhcpcd, everything is fine until the debian-installer try to setup your iface again (with dhcp or manually).

So I opened another telnet session and wrote this dirty little hack that will do the job:

while true; do ifconfig ethX <ip> netmask <netmask>; done

Yes, this is an active loop
Let this script run, go back to your previous telnet session and

$> killall dhcpcd

Yeah !

Installing DEBIAN (YEAH !)

$> debian-installer

Let’s launch the debian installer and follow the instructions. It will complain that it can’t find a suitable kernel, can’t find a suitable bootloader neither, just ignore everything. When it comes to the Partition manager, proceed as follow :

Delete ALL partitions of the two disks.

• Create a new partition (of ~ 512M/1GB) and choose use as physical volume for RAID
• Create another partition of (5GB for exemple) and choose use as physical volume for RAID
• Finally do the same for the rest of the disk (except the last GB)
• Create a swap partition using the last GB of available free space on the disk

Do EXACTLY the same for the second disk.

Once this is done, you can see that on top of the disk#1, you know have a menu called “Configure RAID”. Go into it, accept the warning message (by selecting YES)

The Disk Partionner restarts again and now we have the RAID devices.

• Select the first one and assign it to /boot using ext3
• Select the second one ad assign it to / using ext3
• Select the last one using it for /mnt/array1 using XFS for example.

Write the changes to disks. The debian-installer may complain about not being able to re-read the partition table. DO NOT REBOOT. Just press continue to re try reading the partition table. After some tries, it should be ok.

Make sure that you don’t reboot the NAS at the end of the installation. Instead, open a new telnet session.

restoring the kernel and initrd

$> cp /debian/uImage.buffalo /debian/initrd.buffalo /debian/target/boot

installing the WatchDog monitor

A watchdog is running on the NAS to reboot it in case of a Hanged system. Buffalo’s firmware was running a small piece of code to manage it. Fortunately, the people from nas-central.org have made it available for ourt debian installation.

Download the tar file and extract it in the new environement.

$> cd /debian/target
$> chroot .
$> cd /tmp
$> wget http://buffalo.nas-central.org/download/Users/gnyf/micro_evtd_TSP.tar.gz
$> cd /
$> tar zxvf micro_evtd_TSP.tar.gz

Install SSH server on the NAS

While we are here, we want to install SSH server to make sure that we can connect back to the NAS.

$> apt-get install openssh-server.
$> exit

rebooting (and praying !)

You can now reboot and … pray !

Leave me any comments on improvement of this method that you can find.

A long time ago, I downloaded a .bin/.cue file on my Mac and Suprize ! the famous (un)popular format is not handled by Mac os X (10.5 at least … ) so I couldn’t mount it properly.

As this format is not really a standard, I understand Apple policy to not include any filesystem that support it but it bugs me everytime I want to play around with this kind of file. Of course, the Licensed Software addicts would jump on Toast because it has such feature.

Instead I propose you a (GPL’ed) softwaree that will convert your .bin/.cue file to an .iso image. This format is a supported nearly everywhere and you just have to open the file in Mac os X to mount it and browse the content. This magic software is called bchunk and a version compiled for Mac os X is available here.

Just type the following in your favorite terminal application :

$> bchunk myfile.bin myfile.cue mydestination.iso

$> open mydestination.iso

And voila ! This should do the work.

Refer to James blog for a proper installation of this tool.