FreeS/WAN Project Bows Out 221
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."
The letter (Score:5, Informative)
After more than five years of active development, the FreeS/WAN project will be coming to an end.
The initial goal of the project was ambitious -- to secure the Internet using opportunisitically negotiated encryption, invisible and convenient to the user. For more, see our history page. A secondary goal was to challenge then-current US export regulations, which prohibited the export of strong cryptography (such as triple DES encryption) of US origin or authorship.
Since the project's inception, there has been limited success on the political front. After the watershed Bernstein case, US export regulations were relaxed. Since then, many US companies have exported strong cryptography, without seeming restriction other than having to notify the Bureau of Export Administration for tracking purposes.
This comfortable situation has perhaps created a false sense of security. The catch? Export regulations are not laws. The US government still reserves the right to change its export regulations on short notice, and there is no facility to challenge them directly in a court of law. This leaves the US crypto community and US Linux distributions in a position which seems safe, but is not legally protected -- where the US government might at any time *retroactively* regulate previously released code, by prohibiting its future export. This is why FreeS/WAN has always been developed outside the US (in Canada and in Greece), and why it has never (to the best of our knowledge) accepted US patches.
If FreeS/WAN has neither secured the Internet, nor secured the right of US citizens to export software that could do so, it has still had positive benefit.
With version 1.x, the FreeS/WAN team created a mature, well-tested IPsec VPN (Virtual Private Network) product for Linux. The Linux community has relied on it for some time, and it (or a patched variant) has shipped with several Linux distributions.
With version 2.x, FreeS/WAN development efforts focussed on increasing the usability of Opportunistic Encryption (OE), IPSec encryption without prearrangement. Configuration was simplified, FreeS/WAN's cryptographic offerings were streamlined, and the team promoted OE through talks and outreach.
However, nine months after the release of FreeS/WAN 2.00, OE has not caught on as we'd hoped. The Linux user community demands feature-rich VPNs for corporate clients, and while folks genuinely enjoy FreeS/WAN and its derivatives, the ways they use FreeS/WAN don't seem to be getting us any closer to the project's goal: widespread deployment of OE. For its part, OE requires more testing and community feedback before it is ready to be used without second thought. The project's funders have therefore chosen to withdraw their funding.
Anywhere you stop, a little of the road ahead is visible. FreeS/WAN 2.x might have developed further, for example to include ipv6 support.
Before the project stops, the team plans to do at least one more release. Release 2.06 will see FreeS/WAN making a late step toward its goal of being a simple, secure OE product with the removal of Transport Mode. This in keeping with one of Neils Fergusson's and Bruce Schneier's security recommendations, in A Cryptographic Evaluation of IPsec. 2.06 will also feature KLIPS (FreeS/WAN's Kernel Layer IPsec machinery) changes to faciliate use with the 2.6 kernel series.
After Release 2.06, FreeS/WAN code will continue to be available for public use and tinkering. Our website will stay up, and our mailing lists at lists.freeswan.org will continue to provide a forum for users to support one another. We expect that FreeS/WAN and its derivatives will be widely deployed for some time to come.
It is our hope that the public will one day be ready for, and demand, transparent, opportunistic encryption. Perhaps then some adventurous folks pick up FreeS/WAN 2.x and continue its development, making the project's original goal a reality.
OpenSwan (Score:5, Informative)
There's one more release in the works.... (Score:5, Informative)
Die? (Score:0, Informative)
Re:corporation (Score:5, Informative)
I've taken my Super FreeS/WAN tree, and formed a company with some other ex-FreeS/WAN folks.
Openswan is new name of the project, you can already get code from www.openswan.org [openswan.org].
Commercial support + services from us via Xelerance [xelerance.com]
Ken
KAME (Score:2, Informative)
Either it means, that *YET AGAIN* Linux can't play
nicely, and has to import code from the BSD world
to make things work.
Or, it means nothing, because KAME wasn't imported
to the kernel. Only one or two libraries, and the pfkey code was. And, the userspace KAME tools leave so much to be desired, that nobody would want to
run them.
Openswan lives.
Re:Ouch. This is going to hurt. (Score:5, Informative)
Trolling? Maybe...but here is my experience (Score:5, Informative)
I fought with it for a week - did tons of google research, and still couldn't get Phase2 to work. I eventually caved in and bought a Linksys VPN endpoint router that comes with a simple web administration tool. I had it up and running in 15 minutes. I'm just sorry I wasted that week on FreeSwan.
I'm afraid... (Score:4, Informative)
Re:OSS advocate (Score:2, Informative)
No.
ummm - I have win 98 at home, and when I do a "Windows Update" I see that they are still supporting it. They turned around on their plan to abandon win98 for 12 months I think it was.
so what exactly was your point?
Re:Just to bad, (Score:3, Informative)
From the announcement itself:
That the original group of developers is bowing out has, really, little to no implications for your ability to find support.
Re:Just to bad, (Score:1, Informative)
mod me flamebait but... (Score:2, Informative)
I have to look after a large network of VPNs across a small country and a lot of things about FreeSWAN bite bad wind.
For one thing, not only does it encrypt network traffic; it encrypts its error messages as well. They are all but unintelligible, even after looking at the sourcecode.
Actually, after looking at the sourcecode one is frequently more confused than ever.
And googling for the error messages often seems to find threads where the FreeSWAN developers burble to the effect of "yeah its confusing but I can't be bothered fixing it".
I'm not a developer, but my (highly competent) developer colleague assures me that its 'spaghetti code'.
For another thing, running it over ADSL is a pain in the proverbial; it seems highly intolerant of the so-called 'micro-outages' that pervades ADSL.
Good riddance.
I just hope that we can shift everything over to KAME before the next gaping security hole in FreeSWAN makes its appearance.
Re:OSS advocate (Score:1, Informative)
"Windows 98 and Windows 98 Second Edition support was scheduled to end on January 16, 2004. However, continual evaluation of the Support Lifecycle policy revealed that customers in the smaller and the emerging markets needed additional time to upgrade their product. Therefore, Windows 98, Windows 98 Second Edition, and Windows Me will continue to be supported after January 16, 2004."
Comment removed (Score:3, Informative)
Elucidation (Score:5, Informative)
"Hello World" -> "Uryyb Jbeyq"
triple-DES is a more modern encryption scheme still in use today.
The humor comes from the fact that applying rot-13 twice results in the exact original text, so saying that the Internet uses 'double rot-13 by default' is just noting that it's completely unencrypted but in a way that makes it sound like a real encryption scheme.
It really was quite an amusing post... unlike this one.
Re:Ouch. This is going to hurt. (Score:5, Informative)
I've done a couple FreeS/WAN installs on 2.4 and they were kind of difficult to set up. Not too bad - just painful enough to appreciate them.
However, the other day I decided to try the Linux kernel's new native IPSEC modules (that have been backported to at least 2.4.24). Using 2.4.24 and KAME it was an absolute pleasure to set up. Works beatifully, and no more patching. You couldn't pay me to return to FreeS/WAN.
Re:OSS advocate (Score:2, Informative)
but that's not the point, i was actually talking about the ability for others to pick up a OSS and continue it. simply put, OSS may sleep, but it'll never die completely.
if no one picks it up, that probably means that particular software isn't worth nothing. this is by no mean the end of that software, it's been abandoned, by the source is still open, and maybe in another 50 years, this worthless abandoned source might become useful because of the change in our society.
Re:who cares? (Score:1, Informative)
Note that IPSec is doing a lot more than your ebay example, it allows you to connect two networks together at the IP level. When I VPN into work from home, my computer is actually inside the corporate network, past all the firewalls and security measure. I might as well be sitting at my desk at work...
Re:Doesn't it seem that... (Score:4, Informative)
Why the heck can't IPSec have a set of "must implement" specs so that there could be a standard default config that works with every single ipsec vpn?
Plus, it all runs in userspace, and it works on every single operating system ever, can be port forwarded, natted, mangled in just about every which-way and still works.
What a pleasure to use. Try it. You'll like it.
SSL based VPNs (Score:3, Informative)
Re:corporation (Score:4, Informative)
And 2.1.0rc1 was released a few minutes ago. Need to update website again
Ken
Re:I'm afraid... (Score:4, Informative)
Support for FreeS/WAN will continue, the code certianly won't just wither up and die. A number of us forked it awhile ago, and keep two active trees going for stable and feature development.
www.openswan.org (I've karma whored enough tonight).
Ken
Re:That sucks (Score:1, Informative)
Re:SSL based VPNs (Score:5, Informative)
Typically, an SSL "VPN" is really just a web app that uses ssl between your browser and itself. It runs on a box on the private network, and provides file browsing capabilities, "intranet" access (e.g. an internal purchasing website), etc. But it doesn't let you encrypt your ping packets, since you're not even really connected to the secured network.
I think the companies who created the thing called it a "VPN" because it was the buzzword, and not because it is at all a Virtual Private Network.
Re:Question (Score:3, Informative)
Re:OSS advocate (Score:3, Informative)
When they were in business, they wrote Nautilus, and when they died they left Nautilus as a legacy. Bad economics can kill a company - but it can't kill a good piece of free software.
That said, much of my favourite software was written by zealots [slashdot.org] not companies. (link to other comment on this page, possible scored too low for many people to see.)
Freeswan vs KAME and other useless BS (Score:5, Informative)
And just for the record, tail -f
For those who hated freeswan because error messages sucked, try the above. For those who say it sucked because of politics, welcome to open source!
To me it seems obvious that freeswan will still deployed and maintained -- it's just too good of a thing to let go. Try to think of this as a releasing -- openswan and the rest are not going anywhere. Freeswan's active development is done... since their main goal was OE. Since I didn't want OE, I don't care. It's not like freeswan doesn't support some IPSEC feature or that its behind the times. What else needs to be done? Maintenance I would gather
Considering the responses i've seen here, it's going to be maintained. I'm glad we're in opensource land and I don't HAVE to use kame if I don't want to or have some reason where freeswan is slightly better for my situation.
Re:Ouch. This is going to hurt. (Score:2, Informative)
http://www.ipsec-howto.org/
http://ipsec-tools
Re:perhaps there is another lesson (Score:3, Informative)
I mean, really. From a personal file-sharing standpoint, NFS is retarded.
"Here, connect to my computer. Have a magic cookie or two. Let's cram a stateless protocol into a state-filled paradigm. While we're at it, I trust your computer has not been compromised, and will do all proper authentication. It's only polite, after all."
NFS sort-of works for a pack of servers operating in a firewalled area of the network, but putting one in the DMZ is suicide. When you want to share files from your workstation to mine, it absolutely fails.
Re:Ouch. This is going to hurt. (Score:3, Informative)
http://lartc.org/howto/lartc.ipsec.html [lartc.org]
http://www.ipsec-howto.org/t1.html [ipsec-howto.org]
Get yourself a late model 2.4 kernel and follow the directions for 2.6. Everything works the same. If you use Debian 'testing' or 'unstable' the other packages you'll need are ipsec-tools and then racoon (KAME) or isakmpd.
It's actually pretty easy if you just follow the examples.
Re:Trolling? Maybe...but here is my experience (Score:1, Informative)
For example... By default, phase 1 should be 3DES/SHA1 with a 1440 minute timeout. Phase 2 should be AES128/SHA1 with a 3600 second timeout. The user shouldn't have to care about this unless they need to change the values (which almost noone will need).
The only variable that should have a major impact on the config is the authentication method. So, give a template for {Shared Secret, Certificate, Xauth} authentication - or a script to build it.
Beyond that, they need only know the gateway IP address and the subnet(s) that the gateway is protecting.
Also- IPSec is an excellent solution for remote access VPN's. As long as you are using certificates for authentication, or support versatile authentication via XAUTH, it works great. From the networking perspective, UDP encapsulation avoids many problems with NAT gateways.
Re:Trolling? Maybe...but here is my experience (Score:1, Informative)
Remote access VPNs usually require what the FreeSWAN documentation calls an extruded subnet/ip. There is no built-in way by which an IPSec-"Server" could hand out ip addresses. That is a result of the peer-2-peer design. Instead you have to get by with DHCP-over-IPSec or "left/rightsubnetwithin" (and hope that there are no collisions).
As to the configuration complexity: A simple configuration doesn't need much more than the ip addresses of both sides (potentially with wildcards) and the names of the certificates in one form or another. You can get away with just two parameters for the roadwarrior side: right and rightcert (right will usually be "%any"). The worst part really is to make sense of the left/rightnexthop parameters, which you have to specify for your side of the connection because otherwise FreeSWAN can't figure out how to get encrypted packets onto the net.