Slashdot Mirror
FreeS/WAN Project Bows Out
V. Mole writes "After five years, the FreeS/WAN project has decided to end development. The main reason seems to be that although the project was technically successful, it was not making much progress with its political goals of encrypting a significant portion of all Internet communications, although one might guess that the selection of KAME for the standard Linux IPSEC implementation might also have influenced this decision. And don't panic, the software will remain available, and of course some other group is free to continue development."
This is rather bad news for the not insignificant FreeS/WAN install base out there. The company I worked for last year, for instance, poured a significant quantity of time and money into a corporate VPN based on FreeS/WAN, and even bundled it into products. They don't have the resources or experience to support FreeS/WAN in house themselves, so they'll be in for an intersting ride if problems are discovered. AFAIK, they were hoping not to have to upgrade to Linux 2.6 for at least a year, but that may have to change now. Who all out there is getting left in the lurch by this?
As I understand it, they wanted to use opptunistic encryption to do the "common man" encryption of the 5% of the internet. Has this actually become standard yet? If so, it's only been within the last couple of years I think (since I've stopped dealing with VPN).
Also, aren't there other problems inherant with OE? IE: the need to have secure DNS before this can really happen, or a PKI infrastructure or public key escrow or something? I'd love to just install freeswan on my firewall and have encrypted connections happen, but a) would it really help things and b) would it be like being the first one on the block to have a videophone?
Not if they go out of business, change business models, or decide that a particular product is no longer profitable.
In all of these cases, if you depended on access to and updates for their software, you would be SOL.
With OSS, you get the source code and have the freedom to recompile it to new targets and make whatever small patches are neccessary to keep it running. If it's important enough to your company (or to you as a personal user) you can take over the maintainence yourself.
The parent is alluding to this fact.
It seems that FreeS/WAN's goals of opportunistic encryption were in opposition to the complexity that their implementation required (DNS changes, etc.)
PGP.net (oh, where have you gone) provided opportunistic encryption with no infrastructure requirements other than the two machines communicating use the PGP.net software.
Controlling the two endpoints seems a lot easier than trying to control them plus the DNS servers to exchange info.
Anyone know what happened to PGP.net?
What's wrong with implementing OpenVPN- the SSL approach? I suppose it may be difficult for some companies to upgrade . . . but if they require it, and it is a viable alternative- why not?
Would it really be that difficult for somebody to take over the development? Maybe their role could be more to administer the operation rather than code a lot of it.
Also, this (google's cache) or the PDF version of the above claims that FreeS/WAN does not support PKI.
Actually, I've implemented FreeS/WAN on some VPNs that operate over wireless ISPs in Mexico, and is seems unusually tolerant of the, shall we say, continuous stream of new and exciting conditions that exist on those networks. It's been far more stable than some commercial products we tried (for big $$$).
That being said, I did believe (from reading the docs) that the development team was far more interested in making a (pointless, IMHO) political statement than in creating a useable piece of software. For most small / medium businesses, Oportunistic Encryption is the last thing you want - typically these companies have one interface to the Internet, and having trusted and untrusted-from-random-IP-subnets coming in on the same connection creates a firewall design nightmare. I'm sure there's a way to make it work, but frankly if information is worth securing, we can and do secure it. If it isn't, then we just don't care - I'd rather just Keep It Simple, Stupid.
Help save the critically endangered Blue Iguana
And I can say that it the most obtuse, cryptic product I have ever had to wrestle with.
There was absolutely no way that 'normal' users were ever going to be able to make use of this product for the 'opportunistic encryption' the project aimed for, I honestly don't think you could design a more opaque and confusing piece of software if you were actually trying.
That being said, once you get over the configuration hurdles and realise you will have to employ script-based kludges to do simple things e.g. get it to route packets though multiple tunnels terminating on the same local IP address, it mostly works quite well.
I gots ta ding a ding dang my dang a long ling long
Support from a guy with a slashdot ID that is a 1024 bit RSA encryption key?
I have been doing crypto for a long time now. One of the points that Eric Rescorla raised with me when we were speaking at the RSA show was that more email has been secured with SSL in the first year of deployment than has ever been encrypted with S/MIME and PGP combined.
We all screwed up, Bruce said so in secrets and lies, but he still only half gets it. Almost all the crypto 'truth' turned out to be bogus. End to end crypto is a crock for a start, especially when you try to retrofit to a legacy protocol.
We spent years deplying S/MIME in almost every email reader, but we never made it easy to distribute certs. We also wasted time getting people to implement S/MIME when it would have been better to get them to start by simply not doing harm - if someone gets a multipart/signed message that they don't understand the mail reader should present the signed text without any complaint, just the same as any other unauthenticated content. Same with a message from a person with an invalid or expired cert.
The big screw was messing up the policy aspect. We need an infrastructure to tell people the security that an Internet server supports. DNS is fine for this, as folk point out DNS is secure enough unless there is a pretty difficult active attack.
My criticism of the inanities of the IETF wrt DNSSEC still stand. They just do not understand security there. it would have been better to have deployed DNSSEC with OPTIN two years ago than to continue to wait for all parties to agree on perfection.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
Long time ago there was an awsome program called ecco pro. This program was always highly rated by magazines and users and had a devoted following. Netmanage bought this program from the original company (arabasque) and shortly thereafter shelved it for mysterious reasons (many people suspected MS foul play).
That was a very long time ago and today there is still a vibrant community of ecco users who swear up and down that no other product even comes close. They beg Netmanage to sell the code to them or to open up the source code but Netmanage just ignores their requests. Oddly enough Netmanage does let people download the binary.
To me what netmanage is doing is just cruel. They are not making money off of it, they don't support it and yet they refuse to sell it or open it up. Why did they buy this program for so much money just to mothball it?
Companies are like that. They sometimes suck.
The best way to support the US war effort is to continue buying American products.