Slashdot Mirror
Opportunistic Encryption of IP traffic: FreeS/WAN 2.0
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.
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 DNS on change of IP is easy). Maybe put them (a range of IPs instead of one) in a lower security class if need be.
Belief is the currency of delusion.
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.)
So you'd only be able to use initiate-only opportunism. Oh well, still sucks.
(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.
Yes, DNS is currently the weakest link.
.nl will sign records all the way to the root zone. We need more TLD/gTLD buy-in for DNSSec to become commonplace.
DNSSec will fix most of this, however that requires all of the TLD and gTLD's support it. Currently, only
--
ken@freeswan.ca
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
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.
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 requests and only starts a IKE handshake (See 1 above) if the remote supports OE.
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...
Too bad the FreeS/Wan setup is just way too hard.
I've decided to wait for linux 2.5's native implementation.
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
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.
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.
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 on the attack, and it is feasible when you can redirect traffic (IKE exchange messages) towards you by poisoning the DNS.
If you are using RSA-SIG or RSA-ENCR, ask for certificate, and validate that their ID, their corresponding certificate field, and your idea of their ID match. That'll eliminate almost all the attacks.
Not all. Just poisoning the DNS reply one can DoS you, he may not have any way to establish IKE with you, and get your sensitive traffic sent to him.
Best is to have an ACL, which will authenticate phase 1 SA only if the peer's certificate contains some specific values in their CN/DN and other relevant fields.
-K-