Opportunistic Encryption of IP traffic: FreeS/WAN 2.0 153
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.
Weakest link (Score:5, Interesting)
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)
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.
Re:Weakest link (Score:2)
Re:Weakest link (Score:3, Insightful)
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)
So you'd only be able to use initiate-only opportunism. Oh well, still sucks.
Re:Weakest link (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.
Re:Weakest link (Score:3, Funny)
Now they will be expecting carrier pigeons!
Adi Gadwale.
IP Over Carrier Pigeon (Score:1)
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.
Not expecting them? (Score:2)
Re:Weakest link (Score:1)
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...
Re:Weakest link (Score:1)
MITM protection was the *Point* (Score:2)
Re:Weakest link (Score:1)
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)
DNSSec will fix most of this, however that requires all of the TLD and gTLD's support it. Currently, only
--
ken@freeswan.ca
Re:Weakest link (Score:3, Informative)
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
Re:Weakest link (Score:2)
Someones not going to like this (Score:5, Insightful)
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)
Re:not really (Score:1, Troll)
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.
Re:not really (Score:1)
Re:not really (Score:1)
Innovation happens in multiple places at the same time since the underlying technology becomes available.
Re:not really (Score:1)
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:1)
Re:not really (Score:4, Insightful)
Exactly. They can still target someone who deserves it. However, they can't scan most e-mails, like they are right now [cryptome.org].
Re:not really (Score:2)
Re:not really (Score:5, Informative)
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)
Um...no. Straight single block 56DES has, but streaming and triple block hasn't.
Re: DES, 3DES, RC4 (Score:2)
The only..encryption..the NSA can crack is..DES (Score:1, Flamebait)
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
Re:The only..encryption..the NSA can crack is..DES (Score:2)
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
Re:The only..encryption..the NSA can crack is..DES (Score:2)
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
Re:The only..encryption..the NSA can crack is..DES (Score:2)
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
Re:The only..encryption..the NSA can crack is..DES (Score:2)
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
Re:The only..encryption..the NSA can crack is..DES (Score:2)
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
definition of "easy" (Score:2)
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!
Re:not really (Score:2)
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."
Re:not really (Score:2)
> The only widely used encryption algo that the NSA can crack is 56bit DES
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
That's Deliberate FUD, Troll ! (Score:3)
Possibly not for everyone? (Score:2, Informative)
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)
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
They've disliked it for years. (Score:3, Insightful)
Wireless applications? (Score:4, Interesting)
Re:Wireless applications? (Score:5, Informative)
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.)
Re:Wireless applications? (Score:2)
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
Re:Wireless applications? (Score:1)
You can patch FreeS/WAN to use x509 certificates if you wish.
Yes, that's a VPN (Score:2)
Re:Wireless applications? (Score:3, Interesting)
--
ken@freeswan.ca
Re:Wireless applications? (Score:2)
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
Re:Wireless applications? (Score:1)
Re:Wireless applications? (Score:1)
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)
(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)
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
Routers, and IPSEC vs. SSL (Score:3, Interesting)
This will never work (Score:4, Interesting)
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)
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)
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)
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
Re:This will never work (Score:2)
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....
Deploy and they will stop. (Score:2)
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
Well...if you were hacked...how do you know... (Score:1)
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).
Clueless anti-VPN Cable Modem ISPs (Score:3, Interesting)
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)
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)
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.
Re:This is news? (Score:2)
KEY record debate... (Score:5, Informative)
(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)
Re:SpamStop (Score:2)
For more information, see Policy Groups [freeswan.ca] documentation.
--
ken@freeswan.ca
Re:SpamStop (Score:3, Interesting)
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
Re:SpamStop (Score:3, Interesting)
I have TLS enabled on my MTA (sendmail) and observe the occasional connection that uses it (aside from my own). But, I didn't know how to require encrypted connections. I poked around a bit on the 'Net and found this:
http://www.linuxjournal.com/article.php?sid=4823 [linuxjournal.com]
It appears that you can use the access map to require encypted connections. Of course, the same map could be used to r
Re:SpamStop (Score:2)
in the last week I've had 7 remote hosts (apart from my own workstations) use TLS with my server, and 3 of those were for spam *sigh*
it would be nice if more mailservers supported it
dave
I don't know if this is really a good idea. (Score:4, Interesting)
I realize the point is just to get more encrypted data out on the net, but this just seems pointless to me.
Re:I don't know if this is really a good idea. (Score:2, Insightful)
Re:I don't know if this is really a good idea. (Score:3, Insightful)
Same idea.
-Rusty
Re:I don't know if this is really a good idea. (Score:2)
I think his point is that if you know that some of your mail is being opened then there's little point in sending anything you want kept private even in a proper envelope.
TWW
Re:I don't know if this is really a good idea. (Score:4, Insightful)
This is MUCH better then what we have now, and if you need stronger security, you can use something else instead of/also.
It is foolish to completely trust any internet connections. It is foolish to completely trust anything. There may be a video camera watching your typing and screen, a keyboard logger or rootkit installed on your computer, etc.
Limited security and authentication is so far better then none at all, and you can still do more authentication manually if you want.
The perfect is the enemy of the good.
OE cannot be used by the majority... (Score:4, Informative)
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...
Re:OE cannot be used by the majority... (Score:3, Informative)
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)
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)
There's plenty of current research in this subject, look at Bellovin's paper on Distributed Firewalls as a starting point.
Re:Virus heaven (Score:1)
Re:Virus heaven (Score:1)
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)
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.
Re: not sure you oppose govt. surveillance?? (Score:2, Offtopic)
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
Re: not sure you oppose govt. surveillance?? (Score:3, Interesting)
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)
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.
you don't see as much "terrorism" here because... (Score:1)
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
freeswan setup is just a PITA (Score:1, Informative)
I've decided to wait for linux 2.5's native implementation.
Re:freeswan setup is just a PITA (Score:2)
I think better documentation and/or a better HOWTO would be benneficial.
Another pet peeve of mine is how damned hard using mixmaster remailers is. I've toyed with these things on and off for nearly ten years. I've never really figured it out too well. There aren't even any good
DNS vs IKE key exchange (Score:4, Informative)
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
Re:DNS vs IKE key exchange (Score:1)
Re:DNS vs IKE key exchange (Score:2)
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)
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)
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.
Re:FreeS/WAN IPSEC implementation... (Score:2)
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
Zero Configuration.... (Score:1)
Zero Configuration implies no work done by user.
You contradict that in the rest of your post.
Reverse DNS? (Score:3, Insightful)
One risk of encryption is government searches. (Score:4, Interesting)
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).
Re:One risk of encryption is government searches. (Score:1)
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.
Quick question about implementation... (OE + masq) (Score:2)
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?
Re:You say OE (Score:1)
Most of my background is in WAN engineering and *nix administration, but much of my current paying work is W2K administration (and a bit of *nix). Outlook Express is on my list of software that is not allowed on our company LAN. Why? It's crappy. It has what may be the worst security history of any software product (unless IE is worse), and still isn't RFC-compliant WRT handling PGP-or-GPG-signed email.
My point is that whether or not you think is crappy or not has nothing to