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.
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.
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.
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
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."
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.
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.
Exactly. They can still target someone who deserves it. However, they can't scan most e-mails, like they are right now.
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.
(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.
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.
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.
autopr0n is like, down and stuff.
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.
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.
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...
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.
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
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.
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).
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way