Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Encryption Security

Opportunistic Encryption of IP traffic: FreeS/WAN 2.0 153

Posted by michael from the fight-the-man dept.
Russ Nelson writes "Since 1996, John Gilmore has dreamed of an Internet where all traffic between cooperating sites is encrypted. He has supported the FreeS/WAN project which uses IPSEC to encrypt IP traffic on an opportunistic encrypting basis. The team has released Linux FreeS/WAN 2.00, their first release optimized for Opportunistic Encryption (OE). After installation, ZERO host configuration is required for OE! A Linux box running 2.00 will encrypt all IP packets to other OE capable boxes whenever possible, provided you publish a key and IPsec gateway information in DNS." Nice.
This discussion has been archived. No new comments can be posted.

Opportunistic Encryption of IP traffic: FreeS/WAN 2.0 More

Opportunistic Encryption of IP traffic: FreeS/WAN 2.0

Comments Filter:

  • Weakest link (Score:5, Interesting)

    by gsliepen ( 303583 ) on Saturday May 03, 2003 @11:42AM (#5868919)
    A chain is as strong as its weakest link.
    This applies to cryptography as well.
    In the Oppertunistic Encryption scenario, DNS is probably the weakest link. Spoof KEY records and you can launch a man-in-the-middle attack.

    • Re:Weakest link (Score:5, Insightful)

      by Great_Jehovah ( 3984 ) on Saturday May 03, 2003 @11:47AM (#5868936)
      True. But no one is claiming that OE is something you should depend on. It's main purpose is to make the job of snoops with no resources a lot harder.

      The real weakness in this scheme is that very few admins will go to the trouble of registering keys with DNS due to laziness or lack of perceived value.
    • We need DNS^2: Database Never Spoofed DNS.

    • Re:Weakest link (Score:3, Insightful)

      by Klaruz ( 734 )
      Very few ISPs even let a user control their dns. So it's useless to 90%+ of the broadband users out there.

      Note: I haven't read the article yet, but I'm pretty sure they're talking about reverse dns. I don't see any other way to do it off the top of my head.

      • Re:Weakest link (Score:5, Informative)

        by Klaruz ( 734 ) on Saturday May 03, 2003 @11:59AM (#5868992)
        Determine the best form of opportunism your system can support.


        * For full opportunism, you'll need a static IP and and either control over your reverse DNS or an ISP that can add the required TXT + KEY Records for you.
        * If you have a dynamic IP, and/or write access to forward DNS only, you can do initiate-only opportunism
        * To protect traffic bound for real IPs behind your gateway, use this form of full opportunism.


        So you'd only be able to use initiate-only opportunism. Oh well, still sucks.

    • Re:Weakest link (Score:5, Insightful)

      by gadwale ( 46632 ) on Saturday May 03, 2003 @12:12PM (#5869036) Homepage

      What you have pointed out is true. However, it does not sound like OE is ever meant to protect against main in the middle attacks. By its very definition, it simply encrypts traffic whenever possible. This has two good outcomes:

      1. More encrypted traffic in general, so when you begin encrypting your traffic it does not look suspicious to anybody who is monitoring traffic

      2. Opportunistic sniffers will not be able to read the stream of data since it is automatically encrypted without your having to configure anything

      OE is not a replacement for a VPN, nor is it meant to ensure the identity of the parties involved. If you really wanted to be sure, you would find some other medium to exchange keys initially or ensure that keys you received are signed by a CA or another verifying authority. That way, even if a third party does intercept your data, the data cannot be decrypted without the corresponding private key since you are using the authentic public key and not a spoof.

      Of course, the CA or signing third party may be compromised. In that case, there are only two solutions:
      1. Use telepathic brainwaves
      2. Use carrier pigeons, because nobody will be expecting them

      Adi Gadwale.
      • D U H!

        Now they will be expecting carrier pigeons!

        Adi Gadwale.
        • http://www.ietf.org/rfc/rfc1149.txt [ietf.org]

          A Standard for the Transmission of IP Datagrams on Avian Carriers

          This memo describes an experimental method for the encapsulation of IP datagrams in avian carriers. This specification is primarily useful in Metropolitan Area Networks. This is an experimental, not recommended standard. Distribution of this memo is unlimited.
      • What do you mean, not expecting them [faqs.org]?
      • < 2. Use carrier pigeons, because nobody will be expecting them


        Yeah, it's not like there's an RFC [faqs.org] for that or anything.


        Wouldn't know majesty if it hit him in the face...

      • More realistically, although this is somewhat overkill, you could use quantum cryptography for 100% security.
      • It's very easy to get something like opportunistic encryption if you're not worried about "Man In The Middle" attacks - you do pre-shared secrets, with the standard passphrase "open secret", and that lets everybody set up encrypted connections. They could have had this out a couple of years ago (pre-shared secrets were the standard way to get ipsec boxes from different vendors to talk to each other.) But it falls easily to man-in-the-middle attacks, (to the extent that mitm attacks are easy, which they're

      • Of course, the CA or signing third party may be compromised. In that case, there are only two solutions: 1. Use telepathic brainwaves 2. Use carrier pigeons, because nobody will be expecting them

        Since you've now blown carrier pidgeons as as method for exchanging keys, perhaps you should use the Spanish Inquisition.

        Nobody expects the Spanish Inquisition! Our chief weapon is surprise...surprise and fear...fear and surprise.... Our two weapons are fear and surprise...and ruthless efficiency.

    • Re:Weakest link (Score:5, Informative)

      by velkro ( 11 ) * on Saturday May 03, 2003 @12:33PM (#5869130) Homepage
      Yes, DNS is currently the weakest link.

      DNSSec will fix most of this, however that requires all of the TLD and gTLD's support it. Currently, only .nl will sign records all the way to the root zone. We need more TLD/gTLD buy-in for DNSSec to become commonplace.

      --
      ken@freeswan.ca

    • Re:Weakest link (Score:3, Informative)

      by kousik ( 149219 )
      > In the Oppertunistic Encryption scenario, DNS is probably the weakest link.

      Yes. I wrote the same functionality for my employer. There are several ways to safeguard you.

      The biggest problem is not the key distribution, but if you are using pre-shared keys, then by spoofing DNS and redirecting the IKE messages to an evil host, a dictionary attack on your pre-shared keys may be launched. See a detailed analysis [umn.edu] on the attack, and it is feasible when you can redirect traffic (IKE exchange messages) tow

    • I would think that "Opportunistic Encryption" is an appropriate defence against "Opportunistic Sniffing" - people who are monitoring anybody and everybody just for the heck of it. Predator comes to mind. It wouldn't be easy to man-in-the-middle that much traffic all at once, especially without being very noticeable.

  • Someones not going to like this (Score:5, Insightful)

    by glesga_kiss ( 596639 ) on Saturday May 03, 2003 @11:48AM (#5868940)
    If this becomes popular, I can see the intelligence agencies having a fit. They might lose one of their best information feeds; the internet.

    If this sort of technology were to be rolled into the main distributions as well as Microsoft/Apple packages, the internet would then have a decent level of privacy.

    • not really (Score:2, Insightful)

      by SHEENmaster ( 581283 )
      this uses public-key encryption, which may be an "easy" algorithm but is certainly not secure because given enough clock cycles, the public key can be used to derive the private key. I suspect the NSA has enough computing power to start packet sniffing a particular target within hours if not minutes of this going up.

      • Re:not really (Score:1, Troll)

        by Troed ( 102527 )
        Don't reply to threads when you haven't got a clue on the subject.


        NSA most certainly not has processing power to even begin "sniffing" data encrypted with a knwon good 128 bit stream cipher where the key has been exchanged with 2048 bit DH.

        • ... unless they know a *lot* more math than we do. Which IMHO is unlikely but certainly not impossible.
          • Of course it is. NSA is a company. Company leaks secrets. There's no way anyone working in the feld of Mathematics would be able to keep something that huge a secret for long.

            Innovation happens in multiple places at the same time since the underlying technology becomes available.
            • Of course it is. NSA is a company. Company leaks secrets.

              No. The NSA is a government agency. Government agencies hold secrets better than companies. The NSA in particular has kept a whole lot of crypto secret for a very long time. So while I doubt that they could break RSA at the keylengths used today, it's not impossible.

      • Re:not really (Score:4, Insightful)

        by glesga_kiss ( 596639 ) on Saturday May 03, 2003 @12:09PM (#5869022)
        I suspect the NSA has enough computing power to start packet sniffing a particular target within hours if not minutes of this going up.

        Exactly. They can still target someone who deserves it. However, they can't scan most e-mails, like they are right now [cryptome.org].

      • If anything, the computing power needed to obtain the private key is way too large. It would be cheaper and easier to access the machine that has the private key directly and just make a copy of it.

      • Re:not really (Score:5, Informative)

        by arvindn ( 542080 ) on Saturday May 03, 2003 @12:40PM (#5869177) Homepage Journal
        this uses public-key encryption, which may be an "easy" algorithm but is certainly not secure because given enough clock cycles, the public key can be used to derive the private key.

        Aaargh! Please go read up some crypto. There's no sense in anything you said. You are essentially saying that all crypto is pointless.

        First, public-key encryption is not an "easy algorithm" in any sense. It is much more computationally expensive than symmetric key encryption. Second, adding just a few bits of key size doubles the computational complexity of brute force key search (for public key encryption; for symmetric encryption, adding just a single bit of key length doubles the complexity.) Currently, we are just able to crack 512 bit keys, but most public key encryption today uses 1024 bit keys, so the time taken to bruteforce it would be of the order of countless bajillions of years. The only widely used encryption algo that the NSA can crack is 56bit DES, and it has already been phased out. Third, all real-world crypto needs to use a mixture of public and symmetric key encryption. The former because it is the only one that allows authentication, and the latter because it is much faster.

        I hope that cleared some things up.

        • Re:not really-EOL encryption. (Score:1, Insightful)

          by Anonymous Coward
          "The only widely used encryption algo that the NSA can crack is 56bit DES, and it has already been phased out. "

          Um...no. Straight single block 56DES has, but streaming and triple block hasn't.
          • I don't know what you mean by "streaming", if you're talking about DES at least, but triple-DES is just fine. The effective key length is only 112 bits (2*56) rather than 168 bits (3*56), because of the meet-in-the-middle attack which uses 2**56 objects of memory to reduce the computation time, but that's still pretty good given forseeable technology. (Among other things, hypothetical quantum computers are hypothetically very annoying to factoring-based public-key crypto, but at most provide an N**2 attac
        • The only widely used encryption algo that the NSA can crack is 56bit DES

          Feel free to believe in this yourself, but please do not 'clear some things up' this way for other people. Everything that you've said is on the must be prefaced with It is commonly believed in my circles in block letters.

          WTF is a 'brute force for public key encryption' ? Did you ever heard that assymetric key recovery is essentially a factoring challenge, which is never solved with brute forcing ?

          The DES/NSA statement is simply hil
          • Everything that you've said is on the must be prefaced with It is commonly believed in my circles in block letters.

            Certainly, if you like. But I must also mention that my field is cryptography research.

            WTF is a 'brute force for public key encryption' ? Did you ever heard that assymetric key recovery is essentially a factoring challenge,

            Of course. But I was using bruteforce in a weaker sense, to mean that they can't crack it merely by throwing computing cycles at it (as the original poster meant), wit

            • > The DES/NSA statement is simply hillarious.

              I'll say it again if you want: unless the NSA have developed a different attack on AES or a new factoring algorithm, they can't crack anything that you and I can't.

              Yup. The keyword is "unless". And unless you are an NSA employee, the "unless" will remain a dominating factor in all speculations about what they can and cannot break.

              Sure, but none that can be used when strangers meet for the first time.

              If they are total strangers, nothing will help them t
          • Did you ever heard that assymetric key recovery is essentially a factoring challenge, which is never solved with brute forcing?

            A brute force attack would mean trying all possible factors starting from 3 until you find the right one, which would be at most the square root of the number. And I'm perfectly aware, that there are faster ways to factor. That is part of the reason why people use at least four times as many bits for assymetric encryption than for symmetric encryptions. If you don't think that is
            • And I'm perfectly aware, that there are faster ways to factor.

              Exactly the point. Unlike with symmetric encryption where all but the brute force methods are basically impractical (linear and differential in DES case, for instance), factoring problem has a number of fast non-bruteforce algorithms. And what's more important they all are recent developments. Their young age means there is a good chance for unnamed agency not only to got them developed earlier, but also to already have a faster not-yet-public
              • Their young age

                If you consider 25 years to be young.

                O(exp(c*(ln(n)^1/3*ln(ln(n)^2/3)))

                Can it really done that fast? I don't know the constant c, but if it is smaller than one, that would mean breaking a 1024 bit key would already be feasible. If c was just 0.5, it would be feasible for anybody to even factor a 2048 bit key. If c is more than 2 we are still safe for some time to come. Anyway, I will take your word for it, at least for the duration of this discussion.

                The ^2/3 part can be removed, si
        • One can just send a public key out to anyone who wants it.

          It has nothing to do with the mathematics of the algorithm, which are also rather trivial. Ever seen Cube? Kazan could crack such keys mentally!

        • First, public-key encryption is not an "easy algorithm" in any sense. It is much more computationally expensive than symmetric key encryption.

          Public key encryption is "weaker" in the sense that the ratio between the time taken to decrypt with and without the key is lower. So a much longer key must be used, slowing things down. Since public-key encryption provides far less protection for a given key length [state.md.us], it could fairly be said to be "easier."


        • > The only widely used encryption algo that the NSA can crack is 56bit DES
           ...and you know this... how, exactly?

          Apart from their obvious technological advantage over the mostly amateur or academic (==low funding) cracking projects, there's no guarantee they haven't made some astonishing mathematical breakthrough. Did you know public key crypto was invented at GCHQ (aka MI7, mostly based in Cheltenham - I lived nearby for a while) in the early 70s; the work was never published, and in fact it's signifi
      • The whole point of mathematical cryptography is understanding the work level required to crack it so you can decide whether an algorithm is good enough for what you need. One of the nice things about public-key crypto is that you can make the key longer at roughly N**2 cost, which increases the cracking effort by roughly 2**(N/logN) *, so if you are willing to quadruple your computation time, you increase the cracking effort by a factor of ~2**100, pushing it out of the range of things that can be cracked

    • Possibly not for everyone? (Score:2, Informative)

      by eddy ( 18759 )

      Problem is, the requirements include:

      "* either control over your reverse DNS (for full opportunism) or the ability to write to some forward domain (for initiator-only)
      * (for full opportunism) a static IP"

      Don't know about the US, but over here >90% of all cable/DSL is on dhcp and I'm fairly sure you don't control your reverse-DNS.

      I'm not sure of the role the static IP plays in this, but it would be nice if it could be hacked around so that dhcp-assigned IPs could be used too (scripting updates to D

    • Not really. (Score:3, Insightful)

      by wirelessbuzzers ( 552513 )
      If this becomes popular, I can see the intelligence agencies having a fit.

      Probably.

      They might lose one of their best information feeds; the internet.

      Maybe. The thing is that the intelligence agencies are plagued by too much data, and sniffing the internet doesn't help much. Maybe Carnivore is useful, but I think they probably are having trouble looking through all that.

      f this sort of technology were to be rolled into the main distributions as well as Microsoft/Apple packages, the internet would th
    • John Gilmore and his friends, including the EFF, Cypherpunks, and academic crypto community, have been annoyances to the NSA and their ilk for years. He's done things to them like winning lawsuits in Federal court to get fundamental books on crypto declassified (after doing the search to find one public library that had copies of them), funding the EFF DES cracker machine design to drive the nail into the "56-bit DES is good enough for you" rulemakers (after the "40-bit RC4 is good enough for you" had bee

  • Wireless applications? (Score:4, Interesting)

    by i.r.id10t ( 595143 ) on Saturday May 03, 2003 @11:48AM (#5868941)
    I was wondering... would this have application for wireless, either between a workgroup bridge (like the Ciso one) or a single pci/pcmcia card and an AP or mesh of APs? Seems like it could be better than WEP, especially if it was just as easy to implement on a small scale non-DNS based solution (hosts file, ssid, hard coded ip range, etc.)

    • Re:Wireless applications? (Score:5, Informative)

      by kmcmartin ( 248018 ) on Saturday May 03, 2003 @11:58AM (#5868984) Homepage
      This is a very useful application of IPsec. The wavesec [wavesec.net] project is an example of using IPsec to secure the link between a client and the wireless access point.

      This was in-practice last year at OLS [linuxsymposium.org] where the FreeS/WAN folks set up a wavesec encrypted link, while the folks that were not using wavesec had their traffic snooped and displayed on a monitor.

      The problem with using IPsec as a replacement for WEP, however, is that IPsec is higher up on the OSI layer diagram, so more information is left unencrypted than when using WEP (yes, I'm aware that WEP is weak and in this case, won't make a difference, I'm just illustrating a point.)
      • Yes, because WEP can be used to limit access to your network full stop (putting weaknesses aside). With IPsec, you need to firewall the wireness network and treat it as untrusted, because anyone can get on to it.

        Can IPsec be used with a secure key system, where clients must have a particular key file to get a secure tunnel? If you set IPsec as a requirement (and throw away all other traffic), then you could do something very similar to WEP, but at a IP level. Sure, untrusted clients will be able to associ

        • The Linux Netfilter packet filter has support to filter non-AH or non-ESP packets however you'd like them to be treated. With FreeS/WAN, you can make certain IPs behind your DHCP server available for tunneling, and discard anything else, or anyone without a proper RSA key.

          You can patch FreeS/WAN to use x509 certificates if you wish.
        • VPNs are an easier way to use IPSEC than Opportunistic Encryption is - they're designed for only talking to machines you know and trust and have administrative relationships with, so it's a much simpler problem. As kmcmartin points out, FreeS/WAN has had this since early on (at least in combination with the standard firewalling capabilities.) In addition to letting ipsec packets through, you actually also need to allow UDP 500, which is the connection setup protocols, and you usually want DNS as well, dep

      • Re:Wireless applications? (Score:3, Interesting)

        by velkro ( 11 ) *
        Yup, it was demo'd last year at OLS, and it should be at OLS 2003 as well. (It was my laptop running driftnet showing all the wide open traffic at OLS 2002 - I plan to do the same again this year)


        --
        ken@freeswan.ca

      • The problem with using IPsec as a replacement for WEP, however, is that IPsec is higher up on the OSI layer diagram, so more information is left unencrypted than when using WEP (yes, I'm aware that WEP is weak and in this case, won't make a difference, I'm just illustrating a point.)

        Correct me if I'm wrong, but does it mean that since wavesec/IPsec uses public-key cryptography, each client cannot snoop on each other's traffic (different session keys, and different client public keys), while using WEP e

        • Correct, IPsec can also use a PSK (pre-shared key) so could also be vunerable to that kind of peer snooping. However, RSA is the "recommended" method of operation.
          • However, RSA is the "recommended" method of operation


            Ah, I remember when PGPi moved to ElGamal thanks to the RSA patent. GnuPG still uses ElGamal as well, I think.

            Presumably IPsec started development after the RSA patent elapsed.

  • Pretty cool idea (Score:5, Interesting)

    by VCAGuy ( 660954 ) on Saturday May 03, 2003 @11:51AM (#5868952)
    I think this idea of a "meta-SSL" is a really good one--not only can we encrypt the data stream, but also the headers. Of course, we'd still need to deal with session keys and the problem of "known response" attacks, but assuming we can fix that, this looks really promising.

    (And of course, it would be best if we could implment this on the hardware of the routers themselves, rather than rely on the OS...*cough* M$ *cough*).

    • Re:Pretty cool idea (Score:1, Insightful)

      by Anonymous Coward
      Implementing it only on the hardware of the routers doesn't eliminate the Man in the middle attack though, it just decreases the amount of points at which you can jump in the middle at.

      Sure, if you're 15 hops away from someone and every router between you and the other persons upstream router uses OE, then you've decreased it from 14 possible infilitration points to only 2, but it doesn't eliminate it completely.

      Unless you got everyone to use these routers at home, or added it to cable/dsl modems/etc, y

    • Cisco routers have IPSEC capabilities, if you want to pay extra for the IOS versions that support it. Most Cisco routers have really wimpy CPUs, so if you're trying to handle any real volume, you'll want a crypto accelerator board also. Basically, you end up paying over $5000 for a router that would otherwise be under $2000 (or ~$500 on e-bay :-) (YMMV on Juniper or Lucent or Nortel or other router brands, but it tends to be true there too.) By contrast, a Pentium-200 can pretty much handle IPSEC for a

  • This will never work (Score:4, Interesting)

    by Anonymous Coward on Saturday May 03, 2003 @11:55AM (#5868969)
    Windows 2000 allows one to request IPsec security on all network traffic. All you have to do is flip a switch. I tried this when Windows2k first came out - theoretically, my machine would send a packet to your machine requesting an IPsec connection, your machine responds (either with a "what are you talking about" or "sure, let's do IPsec!") and the connection either gets secured, or dropped back to normal communications. Within a month, I got approximatly 20 calls including three notices from my ISP (UUNET) that I was engaging hacking activity! It's great that some companies actually monitor their network, check their sniffers, and pay people to review the logs, but they should know what an IPsec packet looks like, or at least understand which ports it attempts to authorize over! There was even one company who it ended up being discovered was hacking me!

    Anyway, this will never work - there's too many clueless administrators out there who will think it's just someone attacking their core routers or overloading their DNS server, or something else equally inane, and they won't bother to check what the port really is.

    • Re:This will never work (Score:3, Informative)

      by velkro ( 11 ) *
      OE uses standard DNS requests before attempting to negotiate IPSec tunnels.

      It does a TXT & KEY records, which are perfectly normal and RFC compliant DNS queries. If nothing is found, no IKE negotiation is attempted.

      --
      ken@freeswan.ca

    • Dumb ISPs (Score:5, Interesting)

      by Gothmolly ( 148874 ) on Saturday May 03, 2003 @12:51PM (#5869232)
      Tell those ISPs to go fsck themselves.

      IPSec traffic OFTEN looks like "hack" attacks - weird, short packets, protocol 50 and (sometimes 51), streams of UDP 500, etc. Because it's all binary, its more likely to trigger the "shellcode" sort of alerts. An IDS will see the binary stream "F00F" in your payloads and assume you're doing a DoS attack or something. Trust me, I know - I helped build the first version of Guardent's [guardent.com]IDS solution.

    • Re:This will never work (Score:1, Informative)

      by Anonymous Coward
      Wrong.

      There are tens of millions of port scans every day. Hundreds of thousands of worm infected hosts doing auto-attacking and scanning the internet IP space each day.

      There is so much "bad" traffic on the Internet, nobody cares anymore.

      Other flaws in your idea:

      1. Millions of "road warriors" establish IPSec VNP tunnels back to the home office every day. This uses the same IKE traffic that FreeSWAN OE does. IKE traffic is not bad nor uncommon. I think your story is BS.

      2. FreeSWAN OE, does plain old DNS
    • That's crazy! Plenty of people establish IPSec connections all the time as part of the default configuration for remote VPN access into corporate LANs.

      Any ISP that sees IPSec traffic and thinks you're hacking is #1, spending entirely too much time snooping around what you're doing online, and #2, is clueless and not worthy of your monthly payment.

      I'd certainly not make a statement that "this will never work" based on unknowledgeable ISPs.

      If it catches on, the ISP's will quickly learn about it anyway....
    • Anyway, this will never work - there's too many clueless [ISP] administrators out there who will think it's just someone attacking their core routers or overloading their DNS server, or something else equally inane, and they won't bother to check what the port really is.

      I assume you're talking about ISP administrators, since you mention core routers, and because FreeSWAN won't attempt ANYTHING unusual with an end site unless that site published an invitation in its DNS records.

      Perhaps the scenairo you me
    • There was even one company who it ended up being discovered was hacking me!
      How do you know someone else didn't use your computer to hack, having nothing to do with IPsec?

      Sounds like IPsec is fine and you're just a bad sys admin. (or you use Microsoft Products).
    • I'm really surprised to hear UUNET complaining about IPSEC. They shouldn't care.

      However, there are some cable modem companies that really object to anything VPN-like. It's nothing technical, just pure greed. They assume that if you're using IPSEC, it's a VPN for work, and they have a higher price for "business ISP service" than for "residential". There are even a few DSL companies this rude and clueless. Most Cable modem companies and some DSL companies also object to running anything server-like on

  • A good first step. (Score:3, Funny)

    by Meat Blaster ( 578650 ) on Saturday May 03, 2003 @12:02PM (#5868999)
    FreeS/WAN is definitely on the cutting edge of things, and anything they can do to reduce the complexity of cryptography makes it more likely that a larger audience can realize the benefits of encryption. I applaud this for security reasons, because the less information floating around out the more secure we all are.

    However, this is not yet a complete solution for the average user. For one thing, it's Linux only, which puts it out of reach of the majority. Secondly, and this I absolutely cannot believe, they've killed off Trinity in their Matrix sequel. But most importantly, you've got to have access to DNS to make it properly work!? Why can't a new ICMP handshake be used to exchange keys between a new connection (and queue them) so that this doesn't have to rely on a third-party?

    So, while this is a good first step, I think there are greater things that will yet be accomplished.

  • This is news? (Score:4, Interesting)

    by CoolVibe ( 11466 ) on Saturday May 03, 2003 @12:09PM (#5869026) Journal
    This has been in the works (and working) for quite a while. I saw a presentation by Hugh Daniels in "De Waag" in Amsterdam a couple of years back about FreeS/WAN and opportunistic IPSEC, and he gave a working presentation with live hosts on the net that were using it back then. (Hi Hugh, I was the guy that asked all the good questions, remember me? :)

    But of course it's nice to see this getting more exposure. The problem with IPSEC has always been the hassle of setting it up. Having encryption kick in "automagically", is a good thing to have.

    • It's news - getting this stuff to work has taken them forever, and while some of this has been implementation slowness or tedious debugging that Hugh can rant about, doing Opportunistic Encryption properly is hard, and is harder than it looks, and they kept getting little surprises about what "properly" really did or didn't mean in practice as things that looked like good choices made other things broken. So getting from their aymptotic 1.8, 1.9, 1.9.9, 1.9.9.9, 1.9.9.9.9 to genuine 2.0 is news, because th

  • KEY record debate... (Score:5, Informative)

    by pabl0 ( 228298 ) * on Saturday May 03, 2003 @12:14PM (#5869040)
    One potential problem with this is that KEY records were originally intended for DNSsec usage and some controversy [linuxsecurity.com] has arisen with regard to using KEY records for other purposes, such as OE. This [ietf.org] pretty much sums it up, however, and it seems as though they've gone on using KEY for this purpose.

    (I realize the articles listed are 8-9 months old, but clearly the issue is still relevant.)

    I'm unfortunately not running OE, as my DNS provider (UltraDNS) did not provide the capability to add KEY records to a zone at the time I went through the installation process. Not sure if they do so now; perhaps time to check! I'd be interested in discovering which DNS providers do or do not provide the ability to insert KEY records into zones.

  • SpamStop (Score:4, Interesting)

    by Bruha ( 412869 ) on Saturday May 03, 2003 @12:17PM (#5869059) Homepage Journal
    Wonder if I could just tell my email server to only accept encrypted connections from trusted sources to stop spam. This would definately work for seperate corporate mailservers that need to connect to eachother across the internet eliminating the need to maintain them on a private network.
    • You can do this with FreeS/WAN 2.0 - there is the concept of policy groups. ie: for this set of hosts, only accept crypto connections - if they can't encrypt traffic, I don't want to talk to them. You just stick CIDR blocks into a text file to configure this - it doesn't get much simpler than that.

      For more information, see Policy Groups [freeswan.ca] documentation.

      --
      ken@freeswan.ca

    • Re:SpamStop (Score:3, Interesting)

      by gadwale ( 46632 )

      This may not stop spam, but could make email a much safer medium. Most people have no idea how insecure plaintext email is. Having encryption transparent from the user would be a significant step in the right direction. From the OE docs [freeswan.org]:


      "Only one current product we know of implements a form of opportunistic encryption. Secure sendmail will automatically encrypt server-to-server mail transfers whenever possible."

      Unfortunately the linked paper [usenix.org] is from 1999 and there does not seem to be any updated info

  • I don't know if this is really a good idea. (Score:4, Interesting)

    by autopr0n ( 534291 ) on Saturday May 03, 2003 @12:35PM (#5869144) Homepage Journal
    I mean, you install this thing, and you'll have some random connections be encrypted. But it would still be foolish to 'trust' any regular internet connections. This type of technology might give people a false sense of security.

    I realize the point is just to get more encrypted data out on the net, but this just seems pointless to me.

  • OE cannot be used by the majority... (Score:4, Informative)

    by sweet 'n sour ( 595166 ) on Saturday May 03, 2003 @12:53PM (#5869246)
    Unless you've got a class C or larger ip block to yourself, you probably won't be able to use OE. Dynamic ip addressers need not apply either.

    If you've got a static ip block that is smaller than 255 addresses, most ISPs will only let you assign names/keys/other to your ip addresses through classless reverse delegation (RFC 2317 http://www.ietf.cnri.reston.va.us/rfc/rfc2317.txt) .

    The problem I ran into was that KEY requests never reached my servers (CNAME, TXT, others worked fine). This made it impossible for other OE enabled systems to communicate with me since my box seemed to be configured to talk OE, yet they could never get my key to begin negotiation.

    Another terrible side effect from this was that any OE server I DID try to communicate with would KEEP TRYING to negotiate with me forever until I could get them to shutdown their OE...

    • You can use dynamic IP's for Initiator-Only OE, where you can initiate new OE connections to OE Enabled servers. While others can't start a new connection to you (so running a server on your dynamic IP would be a problem) you can surf OE enabled sites fine.

      Re: KEEP TRYING to negotiate with me forever - this was true in the OE defaults for 1.97 - 1.99. The old default was to rekey forever. In 2.00, rekey is set to "no", so you don't rekey once the SA has expired.

  • Virus heaven (Score:5, Insightful)

    by pseudorandom ( 35988 ) on Saturday May 03, 2003 @12:58PM (#5869271)
    Has anybody thought about the fact that this removes the option of network level filtering? Think about the scenario in which a virus is created that spreads quickly via web servers (e.g. IIS). Currently, it is possible to filter out viral traffic because the routers can inspect the messages. This prevents the spread of the virus even though the hosts/severs remain vulnerable.

    Once all traffic is encrypted using OE, the routers/firewalls cannot recognise the type of traffic anymore, and virii will be able to spread to all vulnerable hosts.

    • Re:Virus heaven (Score:2, Informative)

      by Yostage ( 191211 )
      One solution to this is that you distribute the firewall work and place a firewall on each host. Then the end host will have decrypted the traffic and can analyze the packets in cleartext.

      There's plenty of current research in this subject, look at Bellovin's paper on Distributed Firewalls as a starting point.
    • This does not have to remove ip level filtering, if we all used good network design principles. The perimeter firewall can use OE. The "DMZ" behind that firewall can see the unencrypted traffic, and this is where your webservers should be. The network devices behind the perimeter firewall can then use ip level filtering. Ideally there should be another firewall behind the perimeter firewall as well, to filter packets inbound to the internal networks. Yah, I know this is only applies to ideal setups, an
    • Not really.

      Another host (i.e. your firewall) can perform the opportunistic encryption on behalf of hosts which are situated behind it ('protected' network).

      Like so:

      1.2.168.192.in-addr.arpa. 86400 IN PTR host-1.internal.example.com.
      1.2.168.192.in-addr.arpa. 86400 IN TXT "X-IPsec-Server(10)=1.2.3.4" " AQOyyasaWR008nNRlK9ldRo6ZsbvLXVajgHc1rjrkqIq9hu70 T 8/brFphT36NAZPATajiFC7rT8c7406HCOphVHkMA79BfwPNGX5 kFDfL0kF7aD5YWlXQZdN+vX5uQVPxs7ogECKKd8ftGPNbmarzD 8T0YvnTpgh8F1R7Svot9VIjT1xLR4cD9b4Vy4h9CvgOm

  • Opportunistic encryption for email? (Score:3, Interesting)

    by astrashe ( 7452 ) on Saturday May 03, 2003 @01:02PM (#5869296) Journal
    I really love the idea of opportunistic encryption, and I used to think that I'd like to see it added to email. Once people have exhcnaged mail with each other, all further traffic would be encrypted. This could be done in the clients, and wouldn't require any changes to the email infrastructure at all.

    I know that there are lots of problems with it, mostly related to key management. It wouldn't be perfect security, it might not even be good security. But it's a lot better than plaintext.

    What you'd want would be a way to take control of the keys when you thought it was necessary, an opportunistic system that would get the best key that it could find, but which would allow you to override whatever the opportunistic system would do on its own.

    The problem I have with this now is that I'm not sure I oppose government surveillance any more. It's a horrible thing to say for someone who spent the early nineties lurking on cypherpunks. I think that they've been able to clamp down on terrorism pretty effectively, and I don't see much evidence that the power has been misused.

    I'm getting old, and turning into one of those people I had contempt for -- a guy who is willing to trade freedom for security, and who deserves neither.

    But I do think that from a technlogical standpoint, opportunistic encryption is the way to go. It's a great, clean, simple idea.

    The most successful use of crypto for the general public is SSL on the web. It works because it's transparent, no one has to think about it. That's why opportunistic encryption rocks.

    Perhaps -- and this is a real stretch -- what we really want is a whole new email system, one that's designed to be robust in the face of things like spam, and that includes things like encryption, etc. Dual protocol clients could "opportunistically" move communications from the old system to the new one totally transparently. After a few years, we could all turn off the old email protocol.

    Opportunism is a great way to look at upgrading protocols.

    • Hey! You're never too old to realize trading freedom for security is a bad idea!

      I'm against terrorism as much as the next guy, but let's look at the facts here. Government is never going to release official documents giving true statistics on how often interception of secure communications resulted in capture of a terrorist.

      Say they invade the privacy of 50,000 individuals, and mistakenly go after 25 people from this information. Finally, they get 2 terrorists. What do you think the news is going to s
      • I understand your points, and I really felt the same way before 9/11. And it's a hard thing to talk about, because the government seems to keep a lot of information from us.

        But I wonder: why don't we see more terrorism here than we do? Why do other countries, who are far less involved in the rest of the world, see so much more? It's especially puzzling when you think about how open our society is -- it's easy to move around, to do whatever it is that you want to do.

        Part of it, I think, is that people

        • Re: not sure you oppose govt. surveillance?? (Score:4, Insightful)

          by glesga_kiss ( 596639 ) on Saturday May 03, 2003 @02:55PM (#5869817)
          I understand your points, and I really felt the same way before 9/11.

          So, what exactly has changed? The US psyche has been changed because this is the first time there was a large number of innocents on your home soil. Previously, even during full-scale wars, the US mainland has been safe.

          However, the many parts of the world have had death on their doorsteps for years. Why change your views on privacy and civil liberties on one event? The "Everything changed" thing just isn't true.

          Why do other countries, who are far less involved in the rest of the world, see so much more?

          Most terrorism is related to territorial disputes, e.g Northern Ireland/IRA, Basque Region/ETA and Saudi Arabia/Al Qaeda. Many countries don't have terrorist attacks in them at all, so I wouldn't go so far as to say the US is more or less targeted than anywhere else that has a terrorist problem.

          Also, the US is no more "open" than most places in the free world, where a lot of the terrorism seems to be.

          It is really extraordinary, though, that the US can be as hated around the world as it is, that we can be as open as we are, even going so far as to have lots of the people who hate us living here, and that things are nonetheless quite safe.

          No one hates you. They hate some of the things your government has done. Only extremists see that as validation for killing civilians.

        • ... the government only uses as much "terrorist" incidents as are required to accomplish their tasks.

          Don't get sucked into the propaganda that so many do. OKC, WTC attack 1, WTC attack 2, and the anthrax attacks were all shadow government inspired, lead, allowed to happen, known about in advance, all of the above. they accomplished their tasks. You said
          "And it's a hard thing to talk about, because the government seems to keep a lot of information from us."

          Yes, but sometimes they are lame enough to get cau
  • Too bad the FreeS/Wan setup is just way too hard.

    I've decided to wait for linux 2.5's native implementation.

  • DNS vs IKE key exchange (Score:4, Informative)

    by maynard ( 3337 ) on Saturday May 03, 2003 @01:57PM (#5869569) Journal
    I fiddled with both FreeSWAN and the OpenBSD implementation of IPSEC. Trying to get them to interoperate was a total nightmare, primarily because of the differing key exchange protocols. At the time I wanted to use OpenBSD server side because it supported hardware crypto cards while Linux didn't, which is now a non-issue with current Linux kernels.

    I still think that straight IKE (Internet Key Exchange) is a better method of handling key exchange than DNS - it just seems like we're adding too many unrelated record types to DNS, which is leaving us with a mess of clients/servers that can and cannot understand certain records. The AFS folks have done the same thing, yet I don't see AFS records in DNS maps all over the place. One point I'll make about this, we used to have hesiod records in our DNS maps which we had to rip out when we last upgraded BIND because it didn't understand the record type and would puke and die on startup. DNSSEC only makes the problem worse - unless everyone agrees to support the new record types and upgrades.

    OTOH: automagically performing a key exchange and then setting up a transport mode point to point IPSEC exchange is a very cool thing! Most people think IPSEC is about tunneling whole IP networks within the IPSEC protocol, but ubiquitous transport mode is really the holy grail of IPSEC. Basically it allows one to encrypt any TCP/UDP stream without regard to the underlying port side protocol - thus making ssh, httpssl, ftpssl, etc redundant. Telnet, ftp. http, etc suddenly becomes secure by default without the user having to do or know a damn thing! This is a far more elegant general purpose solution than the variety of encryption schemes we use today, each with their own idiosyncrasies, potential security holes, and command line switches.

    Go FreeSWAN team!

    --Maynard
    • Off topic, but FYI djbdns has support for arbitrary record types, as a good DNS server should.
    • Most people think IPSEC is about tunneling whole IP networks within the IPSEC protocol, but ubiquitous transport mode is really the holy grail of IPSEC. Basically it allows one to encrypt any TCP/UDP stream without regard to the underlying port side protocol - thus making ssh, httpssl, ftpssl, etc redundant.

      True, in the past IPSEC has been about doing the encryption at the gateway instead of between individual systems. There are many reasons for this - firstly the idea of doing the encryption/encapsulatio

  • waiting for free windows client (Score:2, Interesting)

    by Anonymous Coward
    So, other than windows 2000's native IPsec support, is there another (legally) free-as-in-beer IPsec client for commercial windows users?

    The only one I've seen was the one that came from PGPnet or Desktop or something - and it was only free for non-commercial users.

    I know some commercial vendors' vpn clients do support standard IPsec connections (Nortel, Cisco, etc), but AFAIK it's not legal to use them if you haven't bought the company's products...

  • FreeS/WAN IPSEC implementation... (Score:3, Informative)

    by GC ( 19160 ) on Saturday May 03, 2003 @02:45PM (#5869779)
    The FreeS/WAN IPSEC implementation is seperate from the implementation that will be included in the Linux 2.6 kernel.

    The big question is - Is it compatible? and will FreeS/WAN evolve to use the IPSEC implementation.

    I've used 1.9, and it worked fine for me, but I find the iproute2 and IPSEC implementation in the 2.5 development branch of the Linux kernel somewhat more interesting.
    • Slashdot seems to have a short attention span, so I doubt anybody will actually read this post, but here goes...

      The big question is - Is it compatible? and will FreeS/WAN evolve to use the IPSEC implementation.

      Yup, it's compatible. I've already tested the 2.5 IPsec implementation against freeswan 1.9x. No problems there. Linux IPsec uses the KAME racoon and setkey programs for IKE, which are well tested against freeswan. IKE is the hard part, and when people complain about IPsec interoperability, th

  • After installation, ZERO host configuration is required for OE! A Linux box running 2.00 will encrypt all IP packets to other OE capable boxes whenever possible, provided you publish a key and IPsec gateway information in DNS." Nice.
    Zero Configuration implies no work done by user.
    You contradict that in the rest of your post.

  • Reverse DNS? (Score:3, Insightful)

    by Mike Hicks ( 244 ) * <hick0088@tc.umn.edu> on Saturday May 03, 2003 @04:42PM (#5870385) Homepage Journal
    Unfortunately, full opportunism (both incoming and outgoing connections being encrypted) requires you to have a static IP and control over your reverse DNS entries. I will have that someday, but I can't really afford it yet. Also, I doubt many people will jump for that in the future, but I guess one never knows..

  • One risk of encryption is government searches. (Score:4, Interesting)

    by Ungrounded Lightning ( 62228 ) on Saturday May 03, 2003 @05:43PM (#5870702) Journal
    Some time ago a mailing list on a controversial subject was running on my home machine. One of the rules was that no criminal activity could be discussed or facilitated via postings to the list.

    As a matter of policy, while that list was running all traffic both on the list and to and from the machine was UNencrypted.

    The reasoning:

    - Someone unhappy with the subject matter of the list, with being kicked off it for misbehavior, or just mad at the list operators for unrelated reasons, might file a tip with a police agency claiming illegal activity.

    - Due to the list's subject matter, the tip might be considered credible.

    - If the traffic to the site was UNencrypted, they could obtain a wiretap warrant and examine it offsite (and would prefer to do it this way).

    - If any of the traffic to the site was encrypted, they would have to sieze and examine the machine to satisfy their investigation, causing considerable disruption. (And they might also take encrypted traffic as a confirmation of the tip.)

    The list administrator says it well: Leave it unencrypted and they get to bore themselves to tears.

    The list was retired (and a successor started at another site) before I needed to do encrypted traffic between home and work.

    That was quite some time back, and encrypted traffic was uncommon then except for security agencies, a very few businesses, a few experimenters, and a few crooks. At this point encryption is far more common - what with VPN, SSH, and IPSec. And with ready-for-primetime FreeSWAN it will become still more comomn.

    But the core of the original risk is still there: If you're using world-class encryption, and the government gets a bee in its bonnet about you doing something undesirable, they'll need to physically search your machine for evidence or keys, or plant an onsite bug such as a keyboard monitor, to find out what you're up to. (Or they'll find it less expensive to do it that way than try to crack your encryption from outside.)

    Fortunately, a sudden widespread deployment of encryption can get us "over the hump" - going past the point where it is rare enough that security agencies can target people who use it, to the point where wiretapping is pointless and searches on only suspicion-plus-encryption are too expensive.

    That would create an economic incentive to avoid fishing expeditions and mostly search only on credible evidence of wrongdoing (plus an occasional governmental rape of a political enemy or other terrorist action against an outgroup or annoyance-to-cops).
    • Fortunately, a sudden widespread deployment of encryption can get us "over the hump" - going past the point where it is rare enough that security agencies can target people who use it, to the point where wiretapping is pointless and searches on only suspicion-plus-encryption are too expensive.

      As you say, with VPNs, SSH, SSL, IPSec etc., don't you think this has already happened? Plenty of pretty ordinary people are engaging in encrypted sessions all the time.

  • I understand how bidirectional OE works, and how that is neccessary for an OE gateway.

    Question is, anyone know about OE on a masquerading gateway? Their implementation seems to be for a non-masq gateway with DNS records hosted by the ISP.

    Or will a simple bidirectional OE sans gateway mods work for a masq connection?

    Anyone familiar with this?

Slashdot Top Deals

THEGODDESSOFTHENETHASTWISTINGFINGERSANDHERVOICEISLIKEAJAVELININTHENIGHTDUDE

Close