juillet 12, 2006

LED Clear Lenses for my Mazda 3

I just received the pair of LED Clear Lenses for my Mazda 3 Sedan that I ordered on eBay. Let me tell you that it was worth the wait!

There isn't much more to say, so I'll let the pictures speak for themselves.

Before

During

After

While braking

With the hazard and the position lights

The original flasher lights on the car were white, so I had to buy a set of yellow ones for 13$.

Posted by gfk at 8:21 PM | Comments (2)

décembre 16, 2005

Software review: Hamachi

I've been following for some weeks the discussion about VPN on Steve Gibson and Leo Laporte Security Now podcast. This week, they talked about Hamachi, a free VPN client.

I must say that I'm impressed, really impressed, it's a great piece of software. However, I think that I've found a fatal flaw in their design that could sink that Titanic.

What is it?

Hamachi is a small program that stays open in the background, and manages secured connections between computers that you approved. It's available for Windows 2000/XP and i386 Linux, but a MacOSX version should be available Real Soon Now.

Ease of use

The windows version has a graphical user interface that is really easy to use. The first time you install the program, there's a little wizard that explains how to use the most important functions.

Having worked with other VPN products before, I'm absolutely stunned by the simplicity of the system. So little buttons, so little parameters, yet it works on the first try. This is absolutely brilliant, especially when you compare it to the alphabet soup of the other protocols.

Being "born" in the Macintosh world, one thing that particularly irritates me is unusual user interfaces. There are guidelines for making a good user interface, yet smart asses stubbornly continue to invent their own. Specifically, what's driving me nuts with their interface is:

Anyway, I realise that most people won't care about that, so I'll shut-up about it.

NAT traversal

One of the biggest reasons for a network administrator to do acid-reflux is NAT, Network Address Translation. It's a great of way of solving the IP address shortage, but it breaks the network paradigm. Setting up peer-to-peer applications (games, videoconferencing, VoIP, Instant Messaging, etc) is a pain in the butt when dealing with NAT.

The smart people at Hamachi say that they have solved this problem for 97% of the situations. While I don't have proof of this number, I can attest that it worked for 100% of the situations I tested. Thumb's up for that! Sorry Mr. Ebert, I won't do it again...

IP addressing

The first thing that Steve Gibson talked about was the IP addressing used by Hamachi: the 5.0.0.0/8 subnet. This is highly surprising since it's an ICANN/IANA Reserved subnet. In other words they have no right to use it, but they did and it's what makes their program so great. I also believe that's what will make it sink.

When you first log into the program, you get an IP address in the 5.0.0.0/8 subnet -- yes, a public, routable, full blown, IP address. And it's yours, Hamachi guarantees that no one else will get this IP address. This address will be used to reach the computer that this instance of Hamachi is running on using the encrypted network.

The networking type of people reading this will ask the obvious question: Who the fuck do they think they are distributing IP addresses like that? Right now this shouldn't be problem, since the 5.0.0.0/8 subnet is reserved, no one in his right mind would use it. Oops! That's the problem: once another wild kid decides to use that subnet for their own killer application, problems are going to happen.

If Hamachi want to go legit, they'll have to take their protocol to the IETF, ISO or another standard publishing body. Once they do that, the chance that they'll get the 5.0.0.0/8 subnet for their protocol is very slim. That means that you'll have to use another IP address for the "standard compliant" version of Hamachi. Each user will need to reconfigure all of their programs to use the new IP. A nightmare is looming...

In a way, I understand why they did this. If they had gone to a standard body and tried to standardize their protocol, they would have got an answer ranging from "screw you" to "make a working prototype first." After the prototype is made, it takes years for the standard to be approved -- and Microsoft would have patented it while no one was looking.

I'm convinced that using the 5.0.0.0/8 subnet is a dead-end; it's never going to be standard. Hamachi will remain a clever hack, never a serious application. The worst thing here is that they could have avoided this problem, there's a standard that has been designed to avoid this problem: IPv6, the new version of the Internet Protocol. The version of the Internet Protocol used by Hamachi is IPv4.

If an IP address in the IPv4 world is worth 1$/month, it's not worth a penny in the IPv6 world, anyone will get millions of them from their ISP. It's not a problem; it's what IPv6 was designed for. It would be possible to give an IPv6 address to every atom in the universe.

Hamachi could ask ICANN/IANA for an IPv6 subnet and I'm pretty sure that they would get one. Then they could distribute addresses in that subnet with full legitimacy. Every modern OS supports IPv6 now, so the low-level routing that's done by the program would work just as well.

The IP addressing issue is, in my opinion, the worst problem with this system. It's all ready too late to make an easy switch to IPv6 -- it has been since they released that first IP address to the public. The problem is that every minute it gets worse.

Free as in beer

Several companies that try to solve the VPN problem charge a fee for their solutions, Hamachi doesn't. They can do that in part because they don't act as a proxy for the bulk of the encrypted traffic, keeping their bandwidth costs down.

While they provide a Linux version of their program, it's only available in binary form, not open source. It's a bit disconcerting to use a free binary to secure your sensitive data. More importantly I doubt that they'll provide binaries for every esoteric version of Unix out there. What's the good of having a VPN that you can't use on all of your servers?

From a market point of view, this is dangerous too. I'm sure that some open-source zealot will make an open-source clone of Hamachi. After some time, I wouldn't be surprised if the open-source version would be more popular than the official one -- anyone remembers OpenSSH vs ssh®? If Hamachi would release an open-source version of their client, they would avoid that competition, and even get leverage from the bright minds of the open-source world.

Performance

While writing this review, I wondered what performance hit I would get when using the VPN provided by Hamachi. I did some benchmarking with NetPerf.

Benchmark without VPN

This test is done on my local 100 Mbps network, between a Pentium 1.6 GHz with 512 MB RAM running WinXP SP2 and a AMD Athlon XP2000+ 1.3 GHz with 512 MB RAM running Debian testing.

C:\Tele>netperf-a4.exe -H 192.168.0.2
TCP STREAM TEST to 192.168.0.2
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec
 87380   8192   8192    10.00      83.75

Benchmark with VPN

This test was done between the same two machines but using the encrypted tunnel provided by Hamachi.

C:\Tele>netperf-a4.exe -H 5.12.76.70
TCP STREAM TEST to 5.12.76.70
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec
 87380   8192   8192    10.00      23.45

The 72% loss might be a bit impressive but it's important to realise that we're still getting 23 Mbps through this encrypted tunnel. When will you need more than that? Most Internet connections provide a fraction of that. Heck, you could run a dozen high-quality videoconferencing channels through it!

Summary

Pros

Cons

Overall an impressive feat of engineering, I'm using it and I'm happy with it. However, I'm sure that an open-source version that uses IPv6 addresses will eventually kill this bird.

Posted by gfk at 4:23 PM | Comments (6)

novembre 10, 2004

Software review: djbdns

Last year, I discovered djbdns from an article on rootprompt. I spent some time studying the program and summed my toughts in this article.

Software review: djbdns

For years, the de facto standard for DNS has been BIND. In the recent years, other DNS programs have appeared. Most of these newcomers are targeted at big corporations that must manage thousands of zones. These programs often use a database backend. djbdns is different in that it is designed with security in mind. In this article I explain how I see the principles that are the foundation of djbdns and their implications.

The Unix way

The Unix philosophy has always been to make small and specialized programs and to pipe the information from one to the other. On the opposite is the Microsoft approach to make the only program you'll ever need where a spreadsheet, a database and a graphics program are bundled with a word processor.

djbdns follows the Unix philosophy in dividing the task in as much different programs as possible. To have all the features of BIND with djbdns, you'll need 6 different processes running (without counting their child): supervise, multilog, svscan, tinydns, dnscachex and axfrdns. This is a good thing, since these processes don't trust each others, if dnscachex gets corrupted, tinydns will remain sane. This is different with BIND where several attacks are based on corrupting the cache portion of the program to affect the DNS data served.

There's only one way to do it

You may know perl's motto There's more than one way to do it which shows the democratic and freedom values embedded in perl's culture. When I started playing with djbdns, I realised that its motto could be There's only one way to do it. At first sight it might seem like a sad thing to say, but you'll realise that is what the army as been doing all along. And well, the army is known to be secure.

You'll never see an army manual saying:

If you want to clear your rifle, you can start by removing the cartridge, you could also check out if there's a bullet in the chamber. If you feel like it, it is possib le to remove the powder in the chamber or oil the rifle. etc.

This sound pretty awkward and certainly pretty dangerous. As any army soldier will tell you that there is a strict procedure to clean a rifle and not following this procedure can result in lots of trouble for you.

It's the same thing for djbdns, for example, you need to use daemontools to drive you daemon, not TCP wrappers (inetd) or a stand alone daemon. Yep, only one way.

Security wise this really does make sense. Imagine five sequential operations, if there are three ways to do each, then there are 243 (3^5) different possible paths. Each one of these paths must be inspected and tested by the programmer to make sure that it's not possible to abuse it. Most of the times you'll end up with a couples of esoteric paths that have not been correctly tested and end up being exploited. On the other hand, if you only have one path through these five operations, you can expect that the programmer has thoroughly tested it. That's why IPv6 support is still only available as a patch while about every other program has IPv6 support built in. The fact is that IPv6 support build in would only be used by less than 2% of the users and adding complexity to the program for 100% of the users.

I believe that there's only one way to do it is a good thing, it may not be the way that you want to use, but if you're ready to make the sacrifice and use it, you can be sure that it's a pretty safe path.

Disclaimer: I don't know much about guns, so my cleaning procedure is really inaccurate.

No freedom

As with any army, if you're a soldier, you can't tell your Sergeant what you think would be a better way to do something, you must listen to his orders or quit the army. This is the same for djbdns, if you don't agree with a way of doing things, you can write to the mailing list to offer your opinion, but I doubt that it will be incorporated in the main source code. It goes against the there's only one way to do it philosophy, because it would require a lot of efforts to incorporate that change. Of course, this is not as strict as a real army, you can always modify the code source yourself and publish a patch, but you can't publish a modified djbdns. I talk about the strange licensing later.

As long as you trust D. J. Bernstein as your General, you'll be happy in djbdns army. As said differently by some people, djbdns is a good program if you're ready to accept Mr. Bernstein's way of seeing things.

The there's only one way of doing it philosophy can really reduce the excitement and synergy of open-source software, where several people contribute to a program to make it better. That's the price to pay to use this philosophy.

Ingenuity

The traditional way of doing DNS replication of your primary server is using zone transfers. Zone transfers are requests done by secondary servers to the primary server. In order to know when to request a new version of a zone, a serial number polling mechanism has been designed in the protocol. Every couple hours, the secondary servers request, using UDP DNS, the zone's serial number on the primary server. If the serial number is bigger than the one on the secondary server, a DNS zone transfer is requested. Because of size limitations of the UDP datagram, zone transfers have to be done in TCP. As you can see, this procedure is quite awkward and can lead to a lot of problems, including outdated zones on the secondary servers and security vulnerabilities during the zone transfer.

When creating djbdns, instead of blindly implementing the zone transfer mechanism, Dan Bernstein studied what was needed to replicate the primary DNS server on the secondary servers. He realized that the existing polling mechanism was working upside down and that the good way of doing replication was by a push mechanism. The push mechanism can easily be implemented using existing UNIX tools: rsync and ssh.

When the DNS administrator modifies a zone on the primary server, he types make to have it compiled and loaded into tinydns. If there are secondary servers, two lines have been added to the Makefile to launch rsync and send the binary differences immediately to the secondary servers. Since rsync is tunnelled into ssh, the data is encrypted and authentified. The replication is done in seconds, simply, reliably and securely. Absolutely brilliant. Bernstein at his best.

Licensing

djbdns distribution restrictions are quite exotic: you can download djbdns source code free of charge at cr.yp.to (cool address!), you can modifiy that source code at your will, but cannot distribute a modified version of djbdns. You are allowed, however to distribute a patch for people to apply over the unmodified djbdns. My guess is that these distribution restrictions are made to prevent software manufacturer from distributing a broken version of djbdns.

The problem is that most software manufacturers have standard naming procedures, so they often need to modify programs that they distribute so that they respect these standards. They can't do that under that license, that's why RedHat refuses to distribute a djbdns RPM(1). The debian people found a solution to this distribution restriction, they distribute a script that downloads djbdns unmodified from cr.yp.to, applies a patch, then compiles and installs it. This is indeed a very smart trick that completely bypasses the distribution restriction.

I really don't understand why Mr. Bernstein does not release djbdns under a less restrictive license, the debian script really show that this license is easy to bypass, making it totally ineffective. I guess that there's something that I don't understand here, because it seems to me that this licensing only results in problems. In my humble opinion, this restrictive license is the worst problem with djbdns right now.

1: Several individuals have released djbdns RPM, but at the time of writing RedHat has not.

Conclusion

djbdns is a real secure program. Everything has been designed with security in mind. There's even a US$ 500 reward if you can find a security hole in the latest version. To this date, none was found. (Lots of you will say that 500 bucks is worth not much for a security audit, but some people have a lot of free time on their hands these days.) Security has been chosen at the expense of other things, like experimentations and even some parts of the protocol. If you're looking for a production program that is secure and not going to change much, then djbdns is for you. If you want to experiment with DNS and try esoteric sections of the protocol, djbdns will not let you do it.

Posted by gfk at 6:38 PM | Comments (0)