Slashdot Mirror

← Back to Stories (view on slashdot.org)

Opportunistic Encryption of IP traffic: FreeS/WAN 2.0

Posted by michael on 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.

16 of 153 comments (clear)

  1. Weakest link by gsliepen · · Score: 5, Interesting

    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.

    1. Re:Weakest link by Great_Jehovah · · Score: 5, Insightful

      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.

    2. Re:Weakest link by Klaruz · · Score: 4, Informative
      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.

    3. Re:Weakest link by gadwale · · Score: 5, Insightful


      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.

    4. Re:Weakest link by velkro · · Score: 5, Informative

      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

  2. Someones not going to like this by glesga_kiss · · Score: 5, Insightful
    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.

  3. Wireless applications? by i.r.id10t · · Score: 4, Interesting

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

    --
    Don't blame me, I voted for Kodos
    1. Re:Wireless applications? by kmcmartin · · Score: 5, Informative

      This is a very useful application of IPsec. The wavesec 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 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.)

  4. Pretty cool idea by VCAGuy · · Score: 5, Interesting

    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*).

    --
    Q: "Why do sound techs say 'check 1, 2'?"
    A: "Cause if they could count any higher they'd be lighting techs."
  5. This will never work by Anonymous Coward · · Score: 4, Interesting
    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.

  6. KEY record debate... by pabl0 · · Score: 5, Informative
    One potential problem with this is that KEY records were originally intended for DNSsec usage and some controversy has arisen with regard to using KEY records for other purposes, such as OE. This 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.

  7. SpamStop by Bruha · · Score: 4, Interesting

    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.

  8. Re:not really by arvindn · · Score: 4, Informative
    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.

  9. Dumb ISPs by Gothmolly · · Score: 4, Interesting

    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'sIDS solution.

    --
    I want to delete my account but Slashdot doesn't allow it.
  10. OE cannot be used by the majority... by sweet+'n+sour · · Score: 4, Informative
    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...

  11. Virus heaven by pseudorandom · · Score: 5, Insightful

    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.