Charl van Niekerk » Blog: September 2006

Main

Latest

Offline

As some of my readers might know, I am currently in my second year of Software Engineering at UNISA.

During the month of October, I will mostly be offline since I will be studying for and writing exams. I will write my last exam toward the middle of November, but I should be online more after the end of October.

I will still try to come online every couple of days to check my mail, etc, but if you mail me please be patient as I might take a couple of days to reply. Those that have me as an IM contact will also see when I'm online. I do not plan to be on IRC though as I'll have to spend my time online very wisely.

If you need to get in contact with me, please feel free to phone and/or SMS me. I should have my cellphone with me most of the time, although I will have to switch it off while I'm busy writing exams naturally. My cellphone details are on my contact page.

WISP Legality

WISPs are jumping up like flowers in spring in the Garden Route area in South Africa at the moment. They are trying to bypass Telscum's pathetic service (or should I say non-service) to connect them to their clients. Note that they still usually have to buy their upstream bandwidth through a Telscum landline.

Many of these WISPs think they are legal if they have an ICASA VANS licence. This seems to be nothing more than an urban legend though.

I quote the following from an internal ISPA document entitled ISPA Advisory on wireless Internet provision (Microsoft Word document).

It is thus clear that wireless Internet cannot be lawfully provided solely under an existing VANS licence. If the telecommunications facilities are provided by Telkom (or the SNO in due course) and a radio frequency spectrum licence has been obtained, provision of such connectivity may be lawful.

Of course, this is not a legal document, but unless the respective laws changed since the document has been published, it raises serious suspicion.

Also see the ICASA's warning on the use of the 2,4 GHz ISM band (PDF). For more information, check this list of wireless legality stuff.

SSH & HTTP Authentication

One thing I don't really understand is why we still only have extremely primitive methods of authentication with HTTP.

The authentication method I would most like to see implemented at this point in time would probably be something very similar to SSH (the most popular implementation by far being OpenSSH).

So, how does SSH work?

SSH performs an encryption handshake not that dissimilar to SSL. However, instead of using a digital certificate which must be signed by a certification authority (preferably one who's root certificate will be installed in most commonly used web browsers so that your users won't see warnings), it simply sends its public key to the client. The client will normally keep a record of the public keys and ask for confirmation when a new one is added for a new host or issue a warning when the public key on record for a host differs from the one provided (potentially an intruder host cloaking as the real host).

Anyway, this is not of importance for this article. SSL probably works better for the web in this respect. What is of importance here is the authentication from the client.

The client has two options with SSH:

Authenticate using a password
Authenticate using a private/public keypair

The former is pretty standard in web-based applications today. It is the latter which I find ideal though.

Authenticating using a keypair means that the client has to generate its own private/public keypair once. Then the client can issue the public key which is the only thing needed to be put on record on the remote host. The public key is "public" in the sense that it can be public knowledge. You can publish your public key on your website if you like and others can give you access using only that public key. On Unix, an SSH server can give you access to any user account on the system if your public key has been added for that account.

Your private key, on the other hand, must be kept secure. The private key itself will typically be encrypted using a password and stored under the client user's home directory on their own machine with the file permissions set so that only that particular user account can access it.

The reason this works is that the client will (or should) be the only one with access to his/her own private key. Only a private key that matches up with one of the public keys associated with the user account they are trying to log into on the remote server can be used. The private key itself never gets transmitted in any form over the SSH connection; it gets used to encrypt data and if that data can be correctly decrypted using the appropriate public key on the remote server it means that the keys both come from the same keypair.

What it all comes down to is that data encrypted with a private key can only be decrypted with its corresponding public key, and data encrypted with a public key can only be decrypted using its corresponding private key. That's the principle of public key cryptography.

So, what makes this ideal for web-based applications? What are the advantages?

Well, the problems with password-based authentication is that it is dangerous to use the same password for all sites because if one of them turn malicious or get exploited, your password to all the others can fall into the wrong hands, and then you're totally screwed. Have different passwords for different sites, and you are likely to get confused (or write down and/or save your passwords electronically which both can also be dangerous if they are not kept secure).

Also, if the password is not transmitted using high-grade encryption through SSL, it could potentially be sniffed along the way. This is particularly a big concern if wireless networking is used somewhere along the way between the client and the server. There is no "plaintext" option when using private/public key authentication though.

There has been a lot of work so far into creating universal authentication systems. For example, Google Accounts, Microsoft Passport, OpenID, etc.

The problem with the former two is that they are centralised and controlled by their respective companies.

OpenID is my favourite among those mentioned since it is decentralised. However, with OpenID you still need to use a broker. If the broker gets compromised in some way all of its users are at risk.

With SSH, in comparison, as long as your private key is kept secure on your own machine, you should be completely safe (unless in the unlikely event of the underlying crypto being cracked).

The major problem with this is that this system will be quite difficult to get implemented into today's internet as this will require adjustments to specifications, servers and clients. However, I do believe this will be the ideal solution to be implemented in the long term.

The only secure yet realistic alternative I currently know of would be to use long randomly-generated strings of characters for passwords (a different one for each server) and a password manager that saves these passwords to a file (in standardised format) which is encrypted using a master password. However, if you or your software can be tricked into providing the right password to the wrong server, at least one of your user accounts is at risk. Therefore you will need to refuse passwords if the digital certificate of the server doesn't check out completely.

Using private/public key cryptography, you never have this worry because even if you do authenticate against the wrong server, since there is never a password involved and the private key doesn't leave the client's computer, the attackers have nothing they can use to log into the real server afterwards and exploit the user account in question.

Any thoughts?

Interview

I am honoured to have been interviewed by James Yeang from Friedbeef's Tech regarding my Mozilla-related involvement with Translate.org.za and Spread Firefox.

Mono on Ubuntu Dapper

So I have been playing a little with Mono the last while on Ubuntu.

You can install the basic Mono framework (runtime and compilers) using APT (please see the Ubuntu community help page if you are unfamiliar) from the mono package in the Ubuntu main repository. You can also install the MonoDevelop IDE if you want to develop in a GUI using the monodevelop package in the Ubuntu universe repository.

The only thing that is a little tricky is getting mod_mono to run so that you can use ASP.NET.

I decided to try to get it to run on Apache 2. If you don't have that installed already, just install the apache2 package from the Ubuntu main repository.

If that works, then try to install the libapache2-mod-mono package from the Ubuntu universe repository. apache2 is a dependency of this package but it seems a little flaky so best install apache2 first and make sure it works properly in case you need to debug later.

In my experience, after the libapache2-mod-mono package installed, it tried to reload Apache and in the process just hanged. I eventually had to stop the process (sommer a swift Ctrl+C did the trick) and had to fix things up manually.

I had the following files on my system that needed to be renamed:

/etc/apache2/mod_mono.conf.dpkg-new
/etc/apache2/mods-available/mod_mono.conf.dpkg-new
/etc/apache2/mods-available/mod_mono.load.dpkg-new

I just had to rename each of them to remove the trailing .dpkg-new from each filename. (I can't exactly remember if it was .dpkg-new or something very similar as this was a couple of days ago, but you should be able to figure it out when you get there, if you even have this problem in the first place.)

Now all you need to do is move mod_mono.conf and mod_mono.load from /etc/apache2/mods-available to /etc/apache2/mods-enabled and add the following configuration to your vhost:

AddMonoApplications default "/test:/var/www/test"
<Location /test>
 SetHandler mono
</Location>

In this example it will set up the subdirectory /test on the vhost as an ASP.NET site with its files in /var/www/test, but you can set this up any way you like.

If you're not sure where your vhost config is, sommer try the /etc/apache2/sites-enabled/000-default file.

I think this process needs to be streamlined a bit as this is rather complex. According to me, if you install the libapache2-mod-mono you obviously want to use mod_mono so it should immediately be enabled. Also, the fact that you need to set up the handler in the config overcomplicates things even further. This might be because ASP.NET works with Virtual Directories (as they are called in the "official" distribution from Microsoft) but this seems to be changing in ASP.NET 2.0 so let's hope the process will one day be as streamlined as installing PHP.

Anyway, until they get their act together I hope this will help a bit. Please comment / mail me if I can explain or clarify anything further.

For those interested, there are screenshots available also.

Fax to Email & Ownership

There are a number of free fax-to-e-mail services that suddenly popped up in South Africa. Well, by "free" I mean you don't pay, but the person sending the fax does.

I know about the following three services:

The last one on this list looks really unprofessional. What's worse, the latter two seem to be advertising using spam also. (Normally I would definitely not advertise sites that send spam, but I think this is in the public interest.)

Any computer can be transformed into a fax machine by simply installing a modem and some special software. Then the people sending you a fax will get charged normal rates and you will have a flexible and fairly reliable service that you have control over. I would definitely not put my business in the hands of such companies (although I guess SABC Mobile should be fairly respectable).

The issue is also very similar to e-mail addresses. For example, some companies might publish an e-mail address on the domain of their ISP instead of their own domain. This means that if they ever move away from that ISP, they might lose their current e-mail address which can cost them a lot of business.

Also, if you get your ISP or hosting company to register your domain, they might put themselves up as the administrative contact for that domain. This effectively means that, although you're paying for it (through them), they actually own your domain. And if they like they can keep it if you want to move away from them. (This sounds unbelievably unethical, but it happens more often than you might think.)

Play it safe; keep it cool and use your own fax number and e-mail address on your own domain.

Rand Falling

A colleague of mine and I are watching our currency, the SAR, dropping rapidly in value relative to other currencies over the last couple of days.

This is really bad news for South African geeks, hackers, etc. as technology will become even more expensive than it is already in this country. It is good for (some) noobs though in the short term because they will get more money (in rands) when they export products which means they can buy more local products. In the long term, the falling rand will increase inflation and everything will become more expensive anyway. Therefore, I think it would be fair to say that this is a negative thing for everybody at the end of the day.

I am also participating in a forum thread about this issue.

Any thoughts?

SQL on Rails

This is actually quite old, but there still are many people that haven't seen it.

SQL on Rails pokes fun at Ruby on Rails. It is pretty darn ridiculous to any experienced programmer, and probably also to others to a lesser extent.

Download the screencast and the source code and enjoy. :)

Copying files between computers

I discovered quite a cool way to copy directory trees across computers using the tar command in combination with the ssh command.

Previously, I used to do it like this:

tar cjf website.tar.bz2 website
scp website.tar.bz2 remotehost:~/
rm website.tar.bz2
ssh remotehost
tar xf website.tar.bz2
rm website.tar.bz2
exit

Now I can do this in one go:

tar cjf - website | ssh remotehost 'tar xjf -'

Yep, from seven commands to one! :)

If you use - instead of a filename, it will read/write to the standard input/output stream instead of from/to a file. Quite a neat trick.

If you want to copy to a different directory than your home directory, you just need to do a cd before you call the tar command on the remote host. For example, if I wanted to copy the directory directly to the /var/www directory on the remote host, I can do the following:

tar cjf - website | ssh remotehost 'cd /var/www; tar xjf -'

In other words, the website directory will now be located at /var/www/website on the remote host.

If you want to keep the two directories in sync, you can naturally use the rsync command the following times; however, this is more efficient (I believe) for the initial copy.

20 2day!

Yes, today I turn 20. :)

Subversion & mod_security

I was recently setting up a subversion server running through Apache with mod_security enabled. After setting everything up, I tried to test it by doing a checkout and got the following error:

charlvn@example:~$ svn co http://svn.example.com/test
Authentication realm: <http://svn.example.com:80> Example.com Code Repository
Password for 'charlvn':
svn: PROPFIND request failed on '/test'
svn: PROPFIND of '/test': 406 Not Acceptable (http://svn.example.com)
charlvn@example:~$

(Note that I obviously changed the hostname of the server in this example.)

I was quite confused since I never had this problem before. Therefore I did some searching on Google and all I could find was a thread on a mailing list which was inconclusive.

When I checked the error log for the vhost in question, I found the following:

[Tue Sep 12 08:46:46 2006] [error] [client xxx.xxx.xxx.xxx] mod_security: Access denied with code 406. Pattern match "!(^$|^application/x-www-form-urlencoded$|^multipart/form-data)" at HEADER("Content-Type") [severity "EMERGENCY"] [hostname "svn.example.com"] [uri "/test"]

Aha! So it's mod_security that was throwing me around like this!

I then found another thread (again inconclusive) about this issue.

I am obviously not the first one to have this problem; does anybody know of a workaround (other than to disable mod_security altogether)?

Update: Eventually I got it to do an (empty) checkout by using the mod_security configuration rule (before the others):

SecFilterSelective REQUEST_METHOD "^PROPFIND$" allow

However I still could not do checkins. After adding a couple more request methods to the regular expression, some other filters tripped, and we ended up just disabling mod_security for the entire vhost. :)

Google Page Creator on Your Domain

I blogged about Google Page Creator a while back. Google Apps for Your Domain (used to be called "Google Hosted") also offers you Google Page Creator for your own domain now. All the files are hosted on Google's servers; you just create a CNAME record in your DNS to point to their servers and there you go. :)

The markup is still crappy, but that's another matter. Check out my pad (intended to sound hippie-ish) as an example.

So, now you can have your e-mail, instant messaging, calendar and web hosting all handled by Google. All your base are belong to Google! Or alternatively, for unix people:

sudo chown -R google /

Blogger Beta

Finally we are getting a major upgrade to Blogger. Is it going to be that major? I'm not exactly sure yet. But let's hope for the best.

Blogger Beta is out there for anybody that wants to test.

One of the things I thought was odd for a long time is that, although Blogger is now owned by Google, you couldn't use your Google Account to log in. Well, now you can. The only problem is that you have to wait for an invite in order to migrate your existing account. I really don't see what's the point, but oh well. :)

There are quite a couple of interface enhancements but it seems like the improvements so far has all gone into the templating. I was hoping for more and better options, but that hasn't improved much so far it seems.

I opened a test blog so I'll be keeping a keen eye on progress. I'm not that interested in Blogger anymore since I'm more interested in Fidelis at the moment though. Let's hope for better microformats support in the meantime, and if you're really interested take a peek at the Hackosphere.

Windows Live Mail Desktop Beta

Eish. I received this e-mail this morning:

Hello!

You know the beta you've been trying out, Windows Live(TM) Mail beta for the desktop? The one that lets you access your e-mail accounts in one place and organize your messages even when you're offline? Well, we'd like to give you the chance to invite your friends to try it out, too.

Invite your friends

Just a couple things to keep in mind:

Anyone you invite will need to have an MSN® Hotmail® account to try this program. If they don't have a Hotmail account, please send them to www.hotmail.com and have them set one up (this takes only a couple minutes, as you know). Then you can send the invitation to their new @hotmail.com address.

This program is available only in the following countries: United States, United Kingdom, Japan, and Germany. More countries will be coming onboard soon.

Thanks for being part of this.

Best regards,

The Windows Live Mail Beta team

Cool! Only one problem: I stay in South Africa.

Ehm, ok, so why aren't South Africans included in this beta program? Is it because we are all retarded? What exactly is wrong with us? This is why I like to support open source, because there's no discrimination like this. I really hope that the guys from Microsoft will see the light soon and open this beta to all countries.

Glentana

Many of my South African readers will know about the recent floods that hit the Garden Route area. Glentana is one of the towns that were affected the worst. This past Saturday, I made a “draai” there to check things out. Believe me, you won’t understand how bad it is until you’ve seen it. Disaster area, indeed. I (and others) have some photos up for those that might be interested.

I would just like give my condolences to the residents of Glentana, especially to those whose homes were damaged during the recent floods. Our thoughts are with you.

Telecoms Action Group

In my previous post, I mentioned the unacceptably poor condition of the South African telecommunications industry. I also mentioned that we need to take action and not merely complain about it.

I am very thankful to finally see that action is indeed being taken in the form of the Telecoms Action Group. Many thanks to the cool guys of Tectonic for taking the initiative.

The idea is to do something very similar to the Spread Firefox New York Times Ad Campaign.

The first step is to raise 50 000 SAR to pay for an advertisement in a major national newspaper. Believe it or not, 97.2% of this quantity (at the time of blogging) has already been raised. Contributions start from 200 SAR.

Do support this worthy cause. We need to get the word out: Telscum sucks. As teh_pwnerer would have put it, "Telscum licks my balls" (although he probably wouldn't have spelled it as properly).

Telscum has been pwning us for long enough. Let's pwn them for a change and see how they like it. :)

Also see the following resources for more information:

Blog Redesign: Update

Apologies for not blogging more the last couple of weeks. I am currently working on some major projects which are keeping me rather busy. This situation should change in a couple of months after my exams are finished. I am making plans already for December though; if you have cool projects that I might be interested in, please do send me mail so that we can discuss. Otherwise I should have my plate full as-is. :)

Although I think there are still some minor details that need looking at, I am generally quite happy with the new design of this blog. I think this is the best design I managed to come up with for this blog to date. Over time I might get some more inspiration but for now I plan on leaving it mostly as-is.

Please note that I am not at all a designer but rather a coder, so my designing skills are very limited. When I do design, I tend to go for simplicity though.

So far I have mainly done testing in Firefox, but it also seems to work quite well in Opera 9. IE is still a disaster (for now).

I am not entirely finished with the remarkup though. I seriously need to take a look at the document structure in order to make it more accessible (not like it is so bad right now, but it can still do with a lot of improvement).

I am definitely not planning on doing the usual accessibility hacks for current implementations because I prefer to do things properly and let the implementations follow me, not the other way around. Somebody needs to break the vicious circle. But more about that in another post.

It does feel a lot better though to have external stylesheets properly split up according to media type. This means that a user agent will only need to download what they can actually use and can cache it for future use. This does mean that some people might now have caching issues on occasion though, so please make sure you do a proper reload when you visit this blog now to ensure you have the updated stylesheets.

The caching problem is also becoming a particularly big issue in South Africa at the moment thanks to the tons of transparent proxy servers in use. Even local traffic is often being cached. This is in order to try and speed up Internet access while saving bandwidth.

As every South African internet user knows (or should know), our telecommunication industry is suffering under the monopoly of Telkom (or "Telscum" as we prefer to call it locally) and something drastically needs to be done about this or otherwise we will remain in the dark ages of bandwidth forever. When I say this, I mean that we need to actually do something about it and not just sit back and wine, bitch, moan and complain on forums and mailing lists. But more about this in another post. :)

Main

Latest

Archives