Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Encryption Security Privacy The Internet

FreeS/WAN Project Bows Out 221

Posted by timothy from the ideas-don't-die-though dept.
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 discussion has been archived. No new comments can be posted.

FreeS/WAN Project Bows Out More

FreeS/WAN Project Bows Out

Comments Filter:

  • OSS advocate (Score:5, Insightful)

    by maliabu ( 665176 ) on Monday March 01, 2004 @09:46PM (#8435954)
    And don't panic, the software will remain available, and of course some other group is free to continue development

    this is probably one of the reason why OSS is A Good Thing.

  • corporation (Score:2, Interesting)

    by dwgranth ( 578126 )
    I'm sure some corp will pick up the project... I know a lot of people use it.. so i dont really see any reason for it to die

    • Re:corporation (Score:5, Informative)

      by velkro ( 11 ) * on Monday March 01, 2004 @09:54PM (#8436006) Homepage

      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

      • Re:corporation (Score:5, Funny)

        by Fnkmaster ( 89084 ) on Monday March 01, 2004 @10:01PM (#8436056)
        Support from a guy with a two-digit Slashdot User ID... what more could you ask for?

        • Re:corporation (Score:5, Funny)

          by velkro ( 11 ) * on Monday March 01, 2004 @10:05PM (#8436097) Homepage

          Thanks! Some of us have been doing this stuff for many, many years. We might even be good at it by now :)

        • Re:corporation (Score:4, Interesting)

          by Zeinfeld ( 263942 ) on Tuesday March 02, 2004 @12:09AM (#8436980) Homepage
          Support from a guy with a two-digit Slashdot User ID... what more could you ask for?

          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.

      • I've taken my Super FreeS/WAN tree, and formed a company with some other ex-FreeS/WAN folks.

        One of the nice things about OSS is that there is less pressure to continue a bad line of development to "save face" or quell customer concerns. Unlike a commercial project, the OSS community can fork when the developers miss the bus (or make radical course changes when the original developer quits).

        In the case of FreeS/WAN I can only hope that the new maintainers look at the OpenVPN project for inspiration. Th

    • I am sure it will not. FreeSWAN is the most horrible IPSEC stack to be ever written. It is worse then the early Nortel Contivity stack which takes a considerable effort to achieve.

      It was never integrated properly into the networking stack. It never kept up with any of the advanced routing features. It screwed up the interface reporting in a manner which made any dynamic routing daemon go mad. On top of all it does not work on 90% of the more complex interopreability scenarios. The only thing it was useabl

  • The letter (Score:5, Informative)

    by IronBlade ( 60118 ) on Monday March 01, 2004 @09:48PM (#8435967) Homepage
    Dear FreeS/WAN Community,

    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.

    • Re:The letter (Score:2, Interesting)

      by LostCluster ( 625375 ) *
      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.

      Talk about two goals that are just plain swimming uphill.

      Getting the Internet to change what's not broken is very hard. The fact that our default mode of communications is plaintext doesn't quite scare most pointy haired bosses. They want their stuff secured, but there's no sense in switching protocols when we can just secure on top of the existing pro

  • OpenSwan (Score:5, Informative)

    by DivineHawk ( 570091 ) on Monday March 01, 2004 @09:50PM (#8435978) Homepage
    Openswan [openswan.org] is an Open Source implementation of IPsec for the Linux operating system. Is it a code fork of the FreeS/WAN project, started by a few of the developers who were growing frustrated with the politics surrounding the FreeS/WAN project.

  • Ouch. This is going to hurt. (Score:5, Interesting)

    by misspelled ( 740029 ) on Monday March 01, 2004 @09:51PM (#8435982)
    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?

    • Re:Ouch. This is going to hurt. (Score:5, Informative)

      by velkro ( 11 ) * on Monday March 01, 2004 @09:57PM (#8436035) Homepage
      As people have mentioned... the Openswan [openswan.org] project is picking up the slack, and commercial support is also available, directly from current Openswan and ex-FreeS/WAN project folks via Xelerance [xelerance.com].

    • Re:Ouch. This is going to hurt. (Score:5, Informative)

      by ryanvm ( 247662 ) on Monday March 01, 2004 @10:30PM (#8436254)
      Good news - you don't need 2.6 to do native IPSEC.

      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.
    • 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.

      So you worked for a company that bundled something into a product they sell, but has no resources or experience to actually support it? Tell me who they are, so I can avoid them like

  • Opportunistic encryption (Score:5, Interesting)

    by Alan ( 347 ) <arcterex@NOspAm.ufies.org> on Monday March 01, 2004 @09:52PM (#8435990) Homepage
    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?

    • Re:Opportunistic encryption (Score:5, Insightful)

      by Anonymous Coward on Monday March 01, 2004 @10:02PM (#8436068)

      OE doesn't *need* DNSSEC.

      It just benefits from it. Without it, you are vulnerable to *ACTIVE* attacks against the DNS. With DNSSEC, you are totally immune.

      The real thing that bones up OE is that you need a static, public IP (since OE isn't defined for NAT'ed IPsec). If you want to do full OE, then you access to the reverse map too. How many have that? Well, if you don't, you probably don't have static IP or an AUP that even lets you sneeze.

      But, it could be made to work with NAT'ed IPsec, and it could also do enrollment in the reverse map via DHCP.

      • The real thing that bones up OE is that you need a static, public IP (since OE isn't defined for NAT'ed IPsec).

        Hence the emergence of the OpenVPN project. It allows a variety of authentication and encryption methods to connect two hosts that can both have dynamic addresses with forward-only DNS service (such as DynDNS).

    • Yes, it would be like being the first one on your block to have a videophone. How do I know?

      Because I have much the same problem.

      If you are interested in such things on a hobby level, you'd be more than welcome on my own VPN network. We're building secure dns and pki, and it would be cool to have someone else with their own videophone, so to speak...

    • Re:Opportunistic encryption (Score:5, Funny)

      by MrWa ( 144753 ) on Monday March 01, 2004 @10:19PM (#8436190) Homepage
      Also, aren't there other problems inherant with
      OE? IE
      Amoung many other problems, yes, Outlook Express being integrated with Internet Explorer is a problem...
    • OE sounds like a good concept.. But, it may be a solution in search of a problem.

      Securing communication with random parties is nice & all, but I don't really communicate anything worth securing with unknown parties.

      For most people, what's at least as important is a strong authentication that the other side is really the guy I want to talk to. Then, once I know who it is, I want to secure the transaction.

      This is not to say that FreeS/WAN can't accomplish strong authentication.. It supports certific
      • If you want decent security, you not only have to encrypt your interesting conversations, you have to encrypt your boring ones whenever possible, because otherwise the fact that you're having consistent encrypted conversations with a small number of people sticks out like pizza deliveries at the Pentagon.

        Opportunistic Encryption does it mostly correctly, but not in a way that's very practical, because most people don't have control of their reverse DNS space and will therefore never deploy it. Also virtua

  • I thought the Internet was encypted (Score:5, Funny)

    by Anonymous Coward on Monday March 01, 2004 @09:53PM (#8435996)
    It's not triple-DES, but it's double-rot-13. Sounds safe enough.

    • Re:I thought the Internet was encypted (Score:4, Funny)

      by Admiral Burrito ( 11807 ) on Monday March 01, 2004 @11:14PM (#8436581)
      It's not triple-DES, but it's double-rot-13.

      Wrong. Double-ROT-13 was found to be insecure. I mean, come on - it's obvious that the second ROT-13 undoes the first ROT-13! So the internet has since been upgraded to quadruple-ROT-13, which is twice as secure as double-ROT-13.

      • Double-ROT-13 was found to be insecure.

        Yes, it was proven vulnerable to the sophisticated "reading" attack. Microsoft is afraid that if they patch this a new rash of worms will arise, so they recomend upgrading to their most expensive versions.
  • ...from the ending letter:

    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.

  • *gasp!* (Score:3, Funny)

    by homeobocks ( 744469 ) on Monday March 01, 2004 @09:56PM (#8436020)
    You mean my talk sessions through ssh aren't secure any more?!?

    /me puts on his tin foil hat.

  • KAME (Score:2, Informative)

    by Anonymous Coward
    To say that "KAME" was picked is wrong.

    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:KAME (Score:3, Insightful)

      by __past__ ( 542467 )
      How would using BSD code be "not playing nicely"? The whole point of the BSD license is to enable others to use the code, KAME being used by Linux (or Windows or whoever would find a use for it) would be a success for the project.

      It might be an instance of Linux developers failing to produce software that is as good or better than the BSD-licensed alternative (and I don't know either KAME nor FreeS/Wan good enough to say if that's the case), but there is nothing morally wrong about it. Using the best tool

  • Trolling? Maybe...but here is my experience (Score:5, Informative)

    by Anonymous Coward on Monday March 01, 2004 @10:03PM (#8436072)
    In classic Linux fashion, I found FreeSwan complicated and hard to use. It had incredibly obtuse error messages. I couldn't figure out how to configure it (configuring it may be simple, but I couldn't actually figure out _what_ needed to be configured). All I wanted to do was talk to our corporate Sonicwall. All in all a very unpleasant experience.

    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.

    • Re:Trolling? Maybe...but here is my experience (Score:5, Insightful)

      by velkro ( 11 ) * on Monday March 01, 2004 @10:20PM (#8436199) Homepage

      You know what's funny? Recent Linksys VPN routers (ie: WRV54G) use FreeS/WAN for IPsec (they are built on the OpenRG platform).

      So you might be using it anyways ;)
    • I'm currently implementing some pretty small-scale VPN-ification at work. Something to allow traffic between wireless APs and a router to pass over the wired network without mixing the two. Was looking at FreeS/WAN, but I figured what with all the complaints I've seen on the code quality that it'd be better to go with the 2.6 built-in IPSec (which does seem to be available as a backpatch for 2.4). Took me a little while, but I got it working just fine.

      I figured that FreeS/WAN would soon be replaced by

    • Re:Trolling? Maybe...but here is my experience (Score:4, Insightful)

      by imroy ( 755 ) <imroykun@gmail.com> on Tuesday March 02, 2004 @12:27AM (#8437141) Homepage Journal

      I don't think you're alone there. I myself have tried FreeS/wan several times over the years and have always found it a frustrating experience. I think the documentation should take a lot of the blame for the problem. It was never too clear and gave only a few wildly different (and sometimes conflicting) examples. Left side? Right side? They would often switch the left/right-side convention for no apparent reason. And it I found it wasn't always clear what configuration settings were required and how they interacted. Because of this it was hard to condense a working configuration out of the few examples they did give.

      Many years ago I was trying to connect my network with my familys' network (linux to linux) I eventually went with vtun [sourceforge.net]. It worked fairly well. More recently I went with OpenVPN [sf.net] when I needed to connect my dads' Win2K laptop back to the family network over a dial-up line. In both these examples I originally tried using FreeS/wan on the linux side(s). I thought it would be easier (especially with W2K in the second case) because IPsec is a standard. Nope. Now I'll go look at this new Kame [kame.net] port in the 2.6 kernel and IPsec-tools [sf.net]. Hopefully it's fairly easy to setup.

  • I'm afraid... (Score:4, Informative)

    by flogger ( 524072 ) <non@nonegiven> on Monday March 01, 2004 @10:04PM (#8436083) Journal
    I'm afraid that this is going to be the course of all good free/open source software projects. I work in an envioronment that uses Free software for our servers because the schools can't afford others. We've been using Mitel's [mitel.com] SME Server (E-Smith [e-smith.org] for you old-schoolers) for quite a while. Recently Mitel is dropping support for this. This announcement came right after Redhat's shakeup a while back. Free/swan is an excellent tool that we've been using to connect schools and homes. Anyway, I'm afraid that education will suffer, which in turn will lead to everyone's suffering.

    • Re:I'm afraid... (Score:4, Informative)

      by velkro ( 11 ) * on Monday March 01, 2004 @11:25PM (#8436656) Homepage

      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
    • We've been using Mitel's SME Server (E-Smith for you old-schoolers) for quite a while. Recently Mitel is dropping support for this.

      E-smith is nice if you've standardized on it as a single platform, but if you have a mix of different systems it sucks ass. I have a pair of e-smith/SME servers in my office, and our IPSEC guy in our German office practically pulled out his hair trying to get the non-Mitel supported IPSEC stuff to play nicely with their SuSE machines. Eventually, he rebuilt the config file b

  • pgp.net (Score:3, Interesting)

    by Anonymous Coward on Monday March 01, 2004 @10:04PM (#8436084)
    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?
  • FreeSWAN sucks.

    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 i

    • Re:mod me flamebait but... (Score:5, Interesting)

      by ErikTheRed ( 162431 ) on Monday March 01, 2004 @10:37PM (#8436292) Homepage
      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.

  • alternatives (Score:4, Interesting)

    by frazzydee ( 731240 ) on Monday March 01, 2004 @10:15PM (#8436161)
    What's wrong with implementing OpenVPN [sourceforge.net]- 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) [216.239.37.104] or the PDF version of the above [sosresearch.org] claims that FreeS/WAN does not support PKI.
    • What's mainly wrong with the SSL approach is that it's theoretically slower than FreeS/WAN or CIPE. Luckily the SuperFreeS/WAN and OpenFreeS/WAN projects continue to live on.

  • Doesn't it seem that... (Score:4, Insightful)

    by Trolling4Dollars ( 627073 ) on Monday March 01, 2004 @10:15PM (#8436162) Journal
    ...this [sourceforge.net] project would be a little better of a choice for VPN than FreeSWAN? I've been looking it over and it looks pretty cool. I still have to actually try it though.

    • Re:Doesn't it seem that... (Score:4, Informative)

      by nick this ( 22998 ) on Monday March 01, 2004 @10:39PM (#8436309) Journal
      After futzing for the better part of an afternoon trying to get OSX and FreeS/WAN working together, I said "screw it". I downloaded OpenVPN and had it running in literally ten minutes.

      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.
    • Well, sure, there's definitely going to be projects that are much more developed and advanced than FreeS/WAN. But.. this is a sad moment. FreeS/WAN is the innovator, the one that gave that other particular project the momentum to do what it has planned. Truly, it feels like we've lost another legend today. Mabye I'm just an over dramatic nerd, but I really feel like I've suffered a loss.

  • who cares? (Score:3, Interesting)

    by segment ( 695309 ) <sil@po l i t r i x .org> on Monday March 01, 2004 @10:19PM (#8436194) Homepage Journal

    No I'm not trolling I'm asking a question here. Outside of admins, how many people really care whether their connection is secure or not. I always reference this out regarding IPSec and the likes, so I'll point out eBay as an example. Now a company such as eBay in my opinion should have SSL based log on by default, period. It's optional. Why? Because most users outside of the geekrealm, and system admin realm don't understand the escape key from their space bar. So when it comes to things like... "Will you accept this certificate?" and the likes, they don't know, and they certainly don't care. Same goes for VPN's. Why should the people care if Freeswan "was not making much progress with its political goals of encrypting a significant portion of all Internet communications" when the typical user doesn't know about Freeswan, and more than likely wouldn't care.

    • Re: (Score:3, Interesting)

      by account_deleted ( 4530225 )
      Comment removed based on user account deletion
      • SSL is not the one stop security shop people think it is.

        Sure, it's not. Neither are locks on doors on houses.

        To secure your house, you must:
        1) Lock the door.
        2) Lock the windows.
        3) Notify your neighbors when you'll be out of town
        4) Turn on lights
        5) Turn on alarm system
        6) Lock fence gates ... etc...

        But HOW MUCH GOOD IS 2-6 IF YOUR FRONT DOOR IS UNLOCKED?!?!?

        Don't assume that SSL is all that's needed. But don't pretend that it isn't needed.

  • Comment removed (Score:3, Informative)

    by account_deleted ( 4530225 ) on Monday March 01, 2004 @10:20PM (#8436200)
    Comment removed based on user account deletion

  • perhaps there is another lesson (Score:5, Insightful)

    by superwiz ( 655733 ) on Monday March 01, 2004 @10:21PM (#8436208) Journal

    to be learned here. The stated goal of the project was to increase the amount of traffic that is encrypted on the internet. While this does not directly conflict with the goal of making as much software as possible "free" (as in beer), it does set a different goal.

    Why the hell am I bringing this up? Well, one of the problems with FreeS/WAN was that it would not work with low-bit encryption. This was done to promote their political goal. But it also had the side effect of inhibiting adoption at the places where for whatever reason people had to interoperate with low-bit encryption applications or setups. The last time I checked (which I have to admit was over 2 years ago) the FreeS/WAN project explicitly stated that they would refuse to cooperate with anyone who tried "subvert" the project by building-in interoperation with low-bit encryption.

    So what is this lesson to be learned that I am talking about? When fighting an uphill battle (which a volunteer project challenging for-profit institutions always does), it may not be wise to make it more difficult for people on the sidelines to agree with your cause.

    Linux was built on much better technology than Windows (nfs vs smb, ext vs fat, separate windowing subsystem vs windowing system as part of the kernel, etc), but it didn't gain in popularity because it decided it replace all the Windows boxen. The technical decision was made to cooperate with them. The fundamental decision on priorities was to hold interoperability above politics. FreeS/Wan took the other road.

    • No argument on the other two, but I really want to know why NFS is better than SMB.

      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 p

  • Probably a good thing (Score:5, Insightful)

    by The Pim ( 140414 ) on Monday March 01, 2004 @10:31PM (#8436259)
    As someone who's dabbled in FreeS/WAN and IPSEC, I think this may actually help IPSEC on Linux take off. There is now another prominent IPSEC implementation available: the one in 2.6. For a long time, FreeS/WAN was the only choice, and while it was quite good, it had some baggage: Due to legal and political concerns, it was maintained by a relatively closed team, it was never well-integrated into the kernel, and it didn't offer some of the "insecure" features some users wanted. I would argue it was destined to remain a fringe project, never attaining the community acceptance needed for real success.

    The 2.6 implementation is not as mature, but it has excellent success factors. It was written by an alpha kernel hacker, it's in the mainline, and it's open in the Linux tradition. An influx of former FreeS/WAN users may be just what it needs to work out the kinks. FreeS/WAN has done a great service, and is now doing another by throwing its momentum behind an implementation with better long-term prospects.

  • were FreeSwan users afforded "luxury of ignorance" (Score:5, Insightful)

    by totro2 ( 758083 ) on Monday March 01, 2004 @10:31PM (#8436263)
    I've been a Linux user for 10 years, and a Unix System Administrator for 3 years, but Freeswan was among the most challenging things I've ever installed. I found that nothing less than reading the documentation from cover to cover is sufficient to understand it. I'm not suprised that it never caught with any sort of mainstream. Don't get me wrong, I am all for the vision of a secure-by-default internet. But unfortunately, it's so tough to install that only die hard security buffs have the patience to figure it out. Where is the ncurses-based "kernel setup wizard" script with forward and backward buttons? A checklist-based helper to point out what is missing next in getting the damn thing installed properly? A webmin module? A gui based connection configurator, called, say, [g|k]freeswan-conf? ESR has it dead on: without a thick slathering of user friendliness, this sort of project cannot succeed on any widespread level. Them's the breaks. I wish things were diffrent, believe me.
    • Im in a similar boat to you, though with perhaps a little more profesional experience. I can't claim to have gotten through the documentation though.

      Security is directly related to the skill of the admin implementing it. The skill of an admin is directly related to how well that admin understands that tool. Not necessaraly the actual protocols and server bits that make it work, but at least its configuration. My point in experiementing was not to get a single link up, but to eventualy use it for securing W

    • A Webmin module

      Try here [sourceforge.net]. A FreeS/WAN webmin module is standard in the latest release of Webmin. Unfortunately, it does little to unobfuscate FreeS/WAN. I have been looking into FS for the last couple of weeks and was planning on implementing it this weekend at a client's office. Now, I will look at alternatives - lord knows they can't be any more complicated to configure that FS.

  • That sucks (Score:4, Insightful)

    by whois ( 27479 ) on Monday March 01, 2004 @10:35PM (#8436282) Homepage
    As a long time freeswan user I have to say this sucks pretty hard. Having used isakmpd and racoon on openbsd and freebsd respectivly, I've always thought freeswan was easier to configure (but not always easier to get working)

    Hopefully openswan will be a good replacement :)
  • I've spent so many weekends playing with connecting FreeS/WAN to my OpenBSD router. Every time I'd end up with some insanely cryptic error message (on both ends, openbsd isn't much better). This weekend I downloaded KAME for the 2.6 kernel, and had it working within half an hour, including the time to recompile my kernel.

    FreeS/WAN is an unfortunate example of a project too focused on a far out goal (OE) to make the simple foundations work.

  • SSL based VPNs (Score:3, Informative)

    by stonebeat.org ( 562495 ) on Monday March 01, 2004 @11:02PM (#8436462) Homepage
    Wider available of the SSL based VPNs [xml-dev.com] including a OpenSource implementation might be the cause.
    • That won't make thing any easier. SSL VPN is just as complex if not more so. Not to mention that SSL uses more resources than 3DES.

    • Re:SSL based VPNs (Score:5, Informative)

      by jshare ( 6557 ) on Tuesday March 02, 2004 @12:28AM (#8437144) Homepage
      FYI, most of the time when people say "SSL VPN" they don't mean at all the same thing as what Freeswan does. (OpenVPN is an exception).

      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.

  • I use FreeSWAN (Score:4, Interesting)

    by ikekrull ( 59661 ) on Monday March 01, 2004 @11:10PM (#8436543) Homepage
    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.

    • Indeed. Left and right? Why not local and remote? Why didn't it support multiple subnets? I think it needs to be redesigned, with the config in mind. I couldn't care less about OE either - but I do want tunnels that I want setup to work, and work well.
  • FreeSWAN is friggin impossible to configure. So no wonder nobody wants to use it...

    • FreeSWAN is friggin impossible to configure. So no wonder nobody wants to use it...

      True.

      I'm sure it IS configurable, but the documentation is terrible.

      Now, I'm not trying to be a FreeBSD whore... but this is one of the things I was most impressed with so far with FreeBSD.

      IPSec still isn't *really* simple to configure, but at least I managed to get it working within a day.

      I still don't have key exchange working properly between windows and BSD, but I set up a wireless link using BSD to BSD and ipse

  • I'm disappointed that FreeS/WAN is not going to be developed. I guess John Gilmore [toad.com] has lost interest, or decided to stop funding it. Note: who really funds FreeS/WAN is not public (and I do not know), but John Gilmore is widely believed to be one of the major forces behind it.

    I tried to set up OE. In fact, I did have it working, sort of. The problem is that a box running OE presently needs to use another machine as it's nameserver (or at least, use another machine's nameserver in preference to a local

    • >There was talk of fixing this through a port 53 passthrough, but I don't think this ever happened.

      I think this is being fixed in 2.06, so we'll assimilate that chunk of code if it works correctly.

      >Also, OE requires the use of the TXT field. There are many other projects also proposing to use this field (well, a few anti-SPAM proposals), so conflicts could arise in the future.

      You can have multiple TXT records, just like MX, A and other DNS records, so this shouldn't be a problem.

      >However, I hop

  • Why They Weren't Used As Much As They Wanted (Score:5, Insightful)

    by Glug ( 153153 ) on Tuesday March 02, 2004 @12:25AM (#8437132)
    ... not making much progress with its political goals of encrypting a significant portion of all Internet communications ...

    Part of the problem with the FreeS/WAN group was that they DIDN'T WANT TO INTEROPERATE. Their attitude toward single DES was that they refused to support it because it wasn't sufficiently secure. As I recall, they wouldn't even accept patches that provided it as an ifdef with the default turned off. So, they were a pain in the ass to use for any serious interoperative commercial development, which obviously requires stooping to single DES.

    This quote from the FAQ at freeswan.org sums up their attitude regarding interoperability:
    "As we see it, it is more important to deliver real security than to comply with a standard which has been subverted into allowing use of inadequate methods."

    FreeS/WAN saw it wrong. Sure, single DES is not macho enough, but interoperating is pretty damned important, even if that means supporting a protocol that is beneath your 'leetness.
  • OE, or oppertunistic encryption, which is a good thing, in the sense of
    providing seamless ipsec without configuration, depends on having control of
    your reverse dns. A lot of ISPs won't allow you to change or won't change for
    you the reverse, as this is often encoded with useful info for the ISP, such as
    node id, and geographic location. This has had as big an effect at slowing
    down the spread of it as anything else. Some are cool, and I am actually very
    disappointed cause I recommended it to a friend of mine

  • Freeswan vs KAME and other useless BS (Score:5, Informative)

    by razathorn ( 151590 ) on Tuesday March 02, 2004 @01:28AM (#8437490)
    For those of you who say "freeswan was so hard to configure so kame's better freeswan sucks bla bla" or even "kame sucks freeswan is king because kame tools are hard to understand" I have this to say: IPSEC in general is hard to configure... you've got tons of different parameters, hash algs, enc algs, id's, tunnels, ah, esp bla bla bla and if you don't understand the protocol in general then you have no business saying either is hard to configure because you got lucky with one of them and it just worked and now you're married to it and consider it superior. I have used both kame and freeswan and can say with authority, hacking for weeks at a time on custom patchs for freeswan, that they are both good products. I LIKE freeswan more because of it's overall feel of higher quality for managing large numbers of connections and it's general tollerance of other devices that have slightly broken behaiour. For instance, you can turn off rekeying on a connection and let the other side always initiate keying. That is handy. Now I don't agree with their politics and I really could do without them -- I can't say that I much care. Freeswan, in the spirit of open source allowed others to modify it as they see fit. I DID, others did, it worked. Saying the project was worthless without really looking at what it's existance has done and only looking at the fact that some of the politics were bad is most disturbing. I would hate to hear even one of you say BSD sucks because of some configuration issue you had on 386 bsd back in the day.

    And just for the record, tail -f /var/log/auth.log is your friend, as is ipsec auto --status | grep connectionname | grep esp (shows active tunnels)... OH one other thing... if you cant figure out what the other side is configured to when it does phase 1 and phase 2 negotiation, ipsec whack --name connectionname --debug-parsing ; tail -f /var/log/auth.log to tell you EVERY SINGLE ipsec parameter the other side sends you.

    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 .. for a plain old ipsec implementation, it's pretty much done so who can blame em!?

    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.
  • I struggled briefly with FreeS/WAN before getting a flawless working setup between my home net and the PIX at my office. It's exceedingly easy to configure, once you "get it". Never have been able to make it play with a Contivity though.

    If anyone takes over development, I will definitely be testing each new version, at least as it pertains to my setup.

Slashdot Top Deals

Beware of Programmers who carry screwdrivers. -- Leonard Brandwein

Close