Thilo Bangert

Recently I researched cookies a bit and while playing with the cookie related functions in PHP I stumbled upon the HTTPOnly flag.

The purpose of the HTTPOnly flag is to prevent cross-site scripting (XSS) attacks. The idea is, that the browser will use the HTTPOnly-flagged cookie only when doing HTTP requests. It will not, as it normally would, make this cookie available to client side scripting languages (like JavaScript).

The HTTPOnly flag has been introduced by Microsoft as part of Service Pack 1 for Internet Explorer 6, released in September of 2002.

A neat idea, as limiting the possibilities for XSS vulnerabilities can only be good. However, being an extension to the standard, this requires support in both the server and the client. Microsoft did the first step, so how do the other involved parties hold up?

PHP added support for the HTTPOnly cookie in version 5.2, released in November of 2006.

Current releases of Firefox do not support HTTPOnly cookies. Version 3, however, will support HTTPOnly cookies. And Stefan Esser, of Hardened-PHP and suhosin fame, wrote an extension for Firefox 2.0 which supports HTTPOnly cookies.

Opera will support HTTPOnly cookies in version 9.5.

I am not sure whether KHTML or WebKit support HTTPOnly cookies.

Apparently ancient browsers break when asked to process a HTTPOnly cookie. In this day and age this should not be too big a problem however.

It appears, that Microsoft, as unlikely as it may seem, had a pretty decent idea, but the open source community did not respond as one could have hoped.
Is this NIH?

Now, after the LiveJournal incident, which could have been prevented if HTTPOnly cookies were widely supported, an increased effort seems underway to finally get this implemented.

Of course, HTTPOnly cookies do not protect against all types of XSS attacks. Nevertheless, it is another layer of protection for which I am grateful. I was surprised to learn that this was introduced by Microsoft AND that the open source community hasn't adopted this feature more widely. Microsofts positive impacts on this industry do exist afterall...

A year ago, Bruce Guenter released srlog2, which is a secure remote log transmission system. At work we will be wanting centralized logging, which is why I finally hacked on an ebuild for it.

Getting there was a bit tricky, as nistp224 (ebuild) -- an elliptic curve crypto library -- did not compile using gcc-4. Luckily Griffon26 is more asm-savy than I am and within minutes he produced a working patch. (Thanks!)

Anyway - getting srlog2 to work is a breeze:

1. On the receiver aka. central loghost, create srlog2d keys

   
receiver.example.com $ srlog2-keygen -t nistp224 /var/log/srlog2

   The public key will need to be distributed to all sending hosts (see step 5).

2. Set the private key as server key

   
receiver.example.com $ mv /var/log/srlog2/nistp224 /var/log/srlog2/secrets


3. Use the following run file to start srlog2d

   
#!/bin/bash
cd /var/log/srlog2
exec srlog2d srlog2-logger --mkdirs


4. On the sender, create host keys

   
sender-hostname.example.com $ srlog2-keygen -t nistp224 /etc/srlog2

   The public key needs to be put on the receiving host (see step 7).

5. Put the receivers public key into /etc/srlog2/servers/receiver.example.com.nistp224

6. Start a log service. srlog2 takes a log line from standard input and sends it to the central loghost. It is designed to be similar to multilog and thus also supports the patterns.

   
sender-hostname.example.com $ srlog2 bla receiver.example.com
--type stuff--


7. Before the above will work you need to put the senders public key into /var/log/srlog2/senders. Prepend it with its hostname (not fqdn) followed by a semicolon:

   
sender-hostname:nistp224:0kfFexdXjzVPPRQOUbLq3f2K9fDqC2BDsE3o/Q==


Done!

You will now start to see logfiles in /var/log/srlog2/sender-hostname/bla/. If everything worked well, you should be seeing what you typed in step 6.

If you want to use curve25519 instead of nistp224, replace all occurrences of nistp224 above accordingly. However, currently curve25519 is only supported on 32-bit x86.

Note: The example above is only meant to get you up and running. On a production system the server keys would not be stored in /var/log/srlog2. Also be aware of funny line wrapping in the shell commands above.

Update: it was pointed out to me, that dragonheart already had prepared ebuilds for nistp224 and srlog2. And they are much more refined too. Way cool!

Happy hacking!

The other day I updated the red5 ebuild to the most recent version (0.6.1). The red5 release team keeps me informed of releases just before they happen so that we can stay fairly up-to-date... neat!

The company I work for develops learning tools using flash and flex2. For this reason I tried to create an ebuild for mod_flex - an apache module which compiles adobe flex code (.mxml) on the fly... which is great, as you get a .swf back and thus it is much easier to test things during development. Adobe originally provided an installer for the apache module - a horrible idea, as the installer required java and a X terminal and was generally broken (for me). Upon (not only) my complaint, Adobe now distributes a plain old zip file and thus a mod_flex ebuild is a reality. Installer programs are so 1990ies..

enhost - a program which adds system facts (collected using facter from the same author) into a ldap database - is not in the tree (yet) but I've added it to my overlay. Great concept - although enhost could need some love. I am currently investigating server inventory systems for which enhost (or a similar program) could be pretty helpful. This morning I found nVentory which looks promising.

Both facter, enhost and nVentory are written in Ruby. nVentory is web-based and thus uses Rails. In an effort to try to grasp this language I have created some scripts which check the metadata of the portage tree. In turn this resulted in a spree of herd fixing... Thus far I enjoy Ruby and I would not mind doing more with it.

With exams out of the door - I plan on being more present in the community (IRC - uhu)... lets see how that works out.

It appears Richard Stallman is going to be at DTU near Copenhagen this weekend.

He is going to talk about The Danger of Software Patents, a topic covered by him on numerous occasions already. Nevertheless I am planning on being there - give me a shout and we can meet up.

... I really need a Gentoo (t-)shirt...

Fighting patents one by one will never eliminate the danger of software patents, any more than swatting mosquitoes will eliminate malaria.

Richard Stallman

Red5 is an open source flash media server implementation. At work we are using Red5 to allow kids to record themselves, when practicing a foreign language (english)...

So I created an ebuild for it. And now I also have instructions on how to get going on Gentoo... check it out!

Also I

• created an ebuild for nullmodem - see svn - still need to find a category for it...
• tried to make the overlay conform to PMS (which recently has had the first public RFC release)

I briefly looked at PMS today and it feels rather good. I am by no means qualified to judge the technical merit of it, but I recognized much of the it and even learned a bit or two. It feels right to finally put all this into stone. I think it will be for the better of Gentoo and I would like to thank those who have and will improve on it.

Last weekends LinuxForum was really good - I especially enjoyed the PHK talk about varnish.

But also Brian Vinter's talk about the Cell CPU was awesome. The idea that current CPU designs only use 5% of their power to do actual computing, while the rest is spend on branch prediction and caching strategies... amazing.

On Saturday I manned the gentoo 'booth' - we definitively need be better prepared next time! I guess people could hardly recognize what we where representing. As a consequence we were asked a lot if IBM notebooks where any good - as the booth sported somewhere between two to five of those at any one time.

We also had a nice chat with an ubuntu guy - among others we dispelled the old myth of compiling from source, because the programs then will run faster. I guess there are still a lot of people out there spreading this BS. g2boojum fits it rather nicely into:

We're less rules-bound, we tend to favor pragmatism over ideological purity, and we favor flexibility and power over stability.

It was really cool to get to know dercorny and eroyf and jaervosz - i really need to meet more dev's more often. (Sorry Alexander for not being there on wednesday!)

On the otherhand have i gotten hold of a personal dev overlay. genstef outfitted me with the bangert overlay. Thanks a lot.

I have started working on an ebuild for red5 - as I have not done java ebuilds before, that is a bit a challange. I am using the jetty ebuild as a template. Check it out.

Hhm, guess I am starting to get a kick out of this blogging stuff - never expected this to be this long.

The most valuable of all talents is that of never using two words when one will do.

Thomas Jefferson

So I thought: lets give blogging a try. So here you go...

I tried Zimbra the other day - one of the guides in the forum explains how to install zimbra in an Ubuntu chroot. Well, I'd prefer an ebuild, but this one got you up an running fairly fast.

Zimbra seems nice and well thought out. Their performance analysis is impressive. The whole suit is split up into a number of fairly independent components, which makes me believe their numbers

I'll be going to LinuxForum 2007 which is on February 2. and 3. here in Copenhagen. With a bit of luck I'll make it to the business day (the 2.) as well. And I'll get to meet the rest of the danish gentoo crowd. finally...

... so lets see who's the craziest... ...show up if you dare!