Remosi’s Rants

So after reading chipux’s blog entry on TLS Upgrade in HTTP/1.1 I decided that I should get on and do some coding for mozilla, and have an attempt at implementing this. It would solve a problem that I’ve had for ages of virtual hosting SSL connections.

I quickly remembered why I hate state machines, and how complicated HTTP really is, and how complicated SSL is, and trying to do both together is just even more complication. But then, someone pointed out Mozilla bug 116168 (TLS server name indication extension support in NSS). After reading RFC 3546: Transport Layer Security (TLS) Extensions. I decided that it’s probably the better way to go. It allows for virtual hosting more than just HTTP, but SMTP, IMAPS, POPS, LDAPS etc. The bug for this is Mozilla Bug 116169: Browser support for TLS server name indication. So I scrapped my earlier implementation of TLS Upgrade and started implementation on this. It turned out to be very easy, only 20 or so lines of very simple code. The most complicated function is strlen(3). The only problem I had was that the ss->url actually contains a hostname, not a url. Solved.

Now, for a minor diversion. openssl doesn’t seem to support Server Name Indication. So the usual apache SSL libraryes (which use openssl) can’t support Server Name Indication. But chipux to the rescue again, with his mod_gnutls module for apache. This module uses gnutls instead of openssl for providing SSL/TLS support. And gnutls does support Server Name Indication.

So now I have to test my module, and that involves compiling a more up to date version of apache. Sigh.

A lot of people hate reading other peoples code. Especially code bases that are very old. And while I must admit that trying to modify someone elses code is a real pain, sometimes sitting back and reading old code is rather enlightening. You may be sitting there looking at a piece of code trying to figure out what crack the developer was on while they were writing it[1], but you have to remember every line of code is there for a reason. Every single one. The code that half implements some feature is there for a reason. The author obviously decided that it was important to write at some point and then changed their mind. The code which is no longer relevant speaks of a time when that code was relevant. Code that works around some long forgotten bug in some library or kernel, or some limitation of a long dead compiler speaks volumes about what problems people in the past had to face. Code that tries to shave an extra 1kbyte here, and an extra 1kbyte there talks about what hardware that the programmers had to deal with. Code that has massive optimisations performed by hand by the programmer speaks to a time when CPU resources were limited, and the compilers weren’t smart enough to discover the optimisation for themselves. Code that never had any effect is a brief insight into a programmers idea of what the program is doing (even though it’s wrong). Bugs speak about the competancy of the developers and usage patterns of the users. Variable names also show what the developer originally thought was going on when she choose the variable name, (but not necessarily what they realise it does today). Comments provide short sentances in the story of the life of the program. Even which license chosen by the program explains a lot about what the original developer(s) wanted from the program, and what they were hoping to happen to it.

So next time you’re looking at code, cursing and swearing, stop to think about the story of the program. At least it’s an interesting diversion.

[1]: Surprisingly enough, I have found code where the authors do claim to be smoking crack while writing it….