Slashdot Mirror

I don't think that really works, and the request you quote is evidence to support my belief.

This is one case where the a rogue chairman has been clearly identified. Dispite it being obvious that he is (deliberately or otherwise) working against the security of his protocol he has still not being removed. The likelyhood is that this is just the tip of an enormous iceberg. IPSEC was made inordinately complex with far too many different modes of encryption and defaults which didn't turn on automatic encryption. The compexity of IPSEC directly led to the failure of the FreeS/WAN project. It would be very interesting to investigate the NSA links of the people who were involved in designing IPSEC and related protocols.

Do not expect there to be much direct evidence. These are expert professionals subverting the security of our internet systems. The only possible value that NSA experts can have from now on is in identifying flaws in proposed protocols. Even then I would be careful to check that the flaws they point out aren't subtly chosen to support other flaws.

General Public License != Public Domain

It does if you're talking about crypto export rules according to the Wassenaar Arrangement, which defines "in the public domain" very differently from how US copyright law does. See this

It IS the same idea as opportunistic encryption, already supported in FreeS/WAN and OpenSWAN IPSEC .
The FreeS/WAN project died out specifically because the creator was disappointed that no one started using the Opportunistic Encryption portion of the software. See the FreeS/WAN history page for details.
It's great technology, but:
1)not secure until we have secure DNS.
2)somewhat computationally intensive
3)somewhat complex setup

We can fix the first part with DNSSEC. Unfortunately that standard is not getting uptake primarily due to the political issue of who will be in control of the signing key for the root servers.

The 2nd and 3rd issues are what this new project is trying to solve. Unfortunately, by not using already deployed and tested standards like IPSEC, they face an even harder uphill climb then FreeS/WAN did.

I'm of the cypherpunk persuasion, and am doing all I can to push DNSSEC to help enable cool technologies like this, but I realize the rest of the world quite honestly doesn't give a crap. Here's to keeping the dream alive though!

I couldn't find the exact page I wanted (closest I came was their ending letter), but I believe the authors pretty much gave up because they couldn't get political backing for OE. They solved the technical issue (and built a better mousetrap), but could not convince the world to use it.

Opportunistic encryption was the original goal of the FreeS/WAN project. It was not realised, and the eventual forks (OpenSwan and strongSwan) are now aimed more at running IPSEC tunnels.

I believe they called it Opportunistic Encryption. And, actually it died because of the lack of interest from the users (see http://www.freeswan.org/ending_letter.html). But, perhaps now things begin to change with the users caring more about their privacy and a better knowledge of security techniques in general public. I believe IPETEE has the advantage of not relying on DNS fields to publish your key,

The government may have the resources to break strong encryption in real time, but even the largest ISP's do not. So maybe now the FreeS/WAN project no longer sound like tinfoil-hatted paranoiacs when they push opportunistic encryption at every node. Everything gets encrypted automatically and transparently when talking between two OE nodes, regardless of the protocol.

This was their goal, but hostility and forking ensued when most people really wanted to just have an IPsec implementation on Linux. OE is still a good idea, though, and that's what they're focusing on now.

The obvious design win would be if Linksys and Netgear built OE into their consumer grade firewall/routers. Then everyone would have it, not even know it, and when large site operators started deploying it on their network edges, massive amounts of crypto would start traversing the Internet, and no one would be bothered by it.

That's really the key to good system design: add complexity, but don't bother the end user -- it's not his problem.

Actually export laws do exist regards to cryptography technology. Before you declare someone a liar perhaps you should research your facts.

"US laws, as currently interpreted by the US government, forbid export of most cryptographic software from the US in machine-readable form without government permission. In general, the restrictions apply even if the software is widely-disseminated or public-domain and even if it came from outside the US originally. Cryptography is legally a munition and export is tightly controlled under the EAR Export Administration Regulations."

http://www.freeswan.org/freeswan_trees/freeswan-1. 5/doc/exportlaws.html

Remember the idea of opportunistic encryption? If 2 hosts both had the ability to encrypt traffic, the would no matter what the traffic was. This was actually implimented in http://www.freeswan.org/

.. nothing beats FreeS/WAN logo.
What a horrible piece of art, no wonder the project died :-)

The best way to get large parts of the net encrypted would be the opportunistic encryption stuff the FreeS/WAN project was working on. The basic idea was that if you put public keys in DNS, then systems can check for those and apply IPsec encryption to their packets whenever possible. For a good discussion of motives: http://www.freeswan.org/freeswan_trees/freeswan-2. 06/doc/politics.html#policestate The FreeS/WAN project has ended, but at least two descendants were alive & well last I heard, openswan & strongswan, both at .org addresses.

Freeswan tried to do something like this, but gave up due to lack of support from the community. Windows 2000+ have IPSec support built in, but I wouldn't exactly call it "easy" for the end user. (Freeswan was a little difficult as well, even for semi-techies.)

Why not set up a VPN and tunnel Samba through that? That should take care of your fear of insecurity with SMB. Piss easy + secure.

Not sure what software is available for windows, but there is FreeS/WAN for Linux.

tunnel it transparently over ipsec ala isakmpd or frees/wan and tell Reverend^H^H^H^H^H^H^H^HAttorney General Ashcroft to go fuck himself (but not anywhere near singing calico cats).

<tinfoil hat>why? ipsec will give you maybe 30 seconds of chat before our buddies at ft. meade will be able to crack it </tinfoil hat>

Just need to add a good anonymizing network and we'd be all set...

• Loop-back encryption is kinda clunky. dm-crypt looks to be a cleaner way to do encrypted devices. And pam_mount can mount encrypted home directories on login.
• As for doing encryption in the filsystem, several people are at working at it.
• Your notion that OpenSSH only creates a tunnel while the "console" is open, is little more than FUD. Oh no! The console!. That's the whole point. SSH is largely interactive by its very nature.
• It's quite easy to setup OpenSSL in inetd mode for SSL'd services.
• Encrypted executables? Are you joking? WTF would that achieve? If someone has physical access to your machine, you're screwed anyway. And if someone has broken into your machine remotely then your executables are probably the last thing to worry about. On Unix/Linux systems you need root access to write to system executables. If an intruder has root access, they can do anything and don't need to modify your executable to screw around. This is a straw-man argument.
• Linux is very good as a VPN router. Not only do we have IPsec/IPV6 from the KAME project, there's also the (abandoned) FreeS/WAN project and the spin-off Openswan. But don't forget OpenVPN (available for quite a few platforms, not just Unix/Linux). If you're really desperate, you can always combine SSH and PPP to make a VPN.
• Tokens? You have heard of Kerberos haven't you?
  BTW, here's a good LDAPv3+SASL+KerberosV HowTo

My god you are a troll. Oh, and as others have pointed out, encryption does not instantly make something secure.

As a starting point, the WaveSEC homepage describes a way to secure a wireless network entirely using IPsec, without relying on WEP. In addition, for a small home network you can get away with static IP addressing instead of using DHCP, and in this way you can gain all the benefits of WaveSEC security without needing any software patches (since if you look closely all the software patches are DHCP related).

IPsec is supported in Windows 2000 and up, Linux 2.6 (natively) or 2.0 and up (with Free S/WAN patches), and FreeBSD; unfortunately I have no firsthand knowledge of MacOS support. The main drawback of IPsec is that it is a very complicated protocol and takes a lot of effort to set up. Making different systems interoperate with each other is especially challenging -- for this task, I recommend the Free S/WAN interop page which links to an eclectic pile of guides covering most of the possible combinations.

My own home wireless network is a mix of Linux and Windows XP clients all connected via IPsec, and I have much more confidence in its security than I would otherwise have with WEP.

As a starting point, the WaveSEC homepage describes a way to secure a wireless network entirely using IPsec, without relying on WEP. In addition, for a small home network you can get away with static IP addressing instead of using DHCP, and in this way you can gain all the benefits of WaveSEC security without needing any software patches (since if you look closely all the software patches are DHCP related).

IPsec is supported in Windows 2000 and up, Linux 2.6 (natively) or 2.0 and up (with Free S/WAN patches), and FreeBSD; unfortunately I have no firsthand knowledge of MacOS support. The main drawback of IPsec is that it is a very complicated protocol and takes a lot of effort to set up. Making different systems interoperate with each other is especially challenging -- for this task, I recommend the Free S/WAN interop page which links to an eclectic pile of guides covering most of the possible combinations.

My own home wireless network is a mix of Linux and Windows XP clients all connected via IPsec, and I have much more confidence in its security than I would otherwise have with WEP.

8:33pm up 2 days, 22:20, 1 user, load average: 0.00, 0.00, 0.00
37 processes: 35 sleeping, 2 running, 0 zombie, 0 stopped
CPU states: 0.0% user, 7.0% system, 0.0% nice, 93.0% idle
Mem: 2582324K av, 353544K used, 2228780K free, 0K shrd, 82364K buff
Swap: 1073016K av, 0K used, 1073016K free 90972K cached

[root@somewhere]# ipsec eroute | wc -l
393

Dedicated Hpaq Proliant DL380 G3 server, Xeon 2.8Ghz CPU, 2+GB RAM. Multiple site-to-site tunnels up to about 130 sites across WAN links of varying speed, but mostly between 3-8Mbit/s. Handles about 1.2GB of 3DES/MD5 encrypted/authenticated traffic per day. Runs like a champ, the box barely notices the encryption overhead, it just takes a while (2-3 minutes) to rebuild all the tunnels when you restart FreeS/WAN.

Only headache is deciding which open-source VPN/ipv6 software to use now that FreeS/WAN is at end-of-life.

8:33pm up 2 days, 22:20, 1 user, load average: 0.00, 0.00, 0.00
37 processes: 35 sleeping, 2 running, 0 zombie, 0 stopped
CPU states: 0.0% user, 7.0% system, 0.0% nice, 93.0% idle
Mem: 2582324K av, 353544K used, 2228780K free, 0K shrd, 82364K buff
Swap: 1073016K av, 0K used, 1073016K free 90972K cached

[root@somewhere]# ipsec eroute | wc -l
393

Dedicated Hpaq Proliant DL380 G3 server, Xeon 2.8Ghz CPU, 2+GB RAM. Multiple site-to-site tunnels up to about 130 sites across WAN links of varying speed, but mostly between 3-8Mbit/s. Handles about 1.2GB of 3DES/MD5 encrypted/authenticated traffic per day. Runs like a champ, the box barely notices the encryption overhead, it just takes a while (2-3 minutes) to rebuild all the tunnels when you restart FreeS/WAN.

Only headache is deciding which open-source VPN/ipv6 software to use now that FreeS/WAN is at end-of-life.

Just have everyone setup opportunistic IPsec tunnels with each other and all data passing through any IP protocol would be encrypted to anyone who also is running IPSec that way.

Amen to that - PSTN was never secure. VoIP can be MUCH more secure. Starting with the ability to control who calls you, where they come from, and whether or not they are impersonating someone else. Even PSTN CallerID is trivially spoofable. What privacy? Get OE. Start with encrypting everything - check out http://www.ietf.org/internet-drafts/draft-richards on-ipsec-opportunistic-13.txt and http://www.freeswan.org/freeswan_trees/freeswan-2. 05/doc/quickstart.html A future revision will explain how to do it through NATs. What? Your VoIP box doesn't support OE? Tell your vendor to fix it, or put it behind a Linux firewall.

Perhaps Freeswan went into retirement a bit too soon. Freeswan offered ubiquitous encryption throughout the internet where computers would negotiate secure transport mechanisms with each other on an opportunistic rather than pre defined basis.

While this isn't bad there are better ways to secure your ports. Firstly many are calling this security through obscurity when it's really just another layer of password protection with knocks on ports substituted for a text string.

It does have problems. It doesn't use much information and it does not provide authentication. I.e. when someone successfully "authenticates" you only know that someone knocked on the ports in the right sequence from machine w.x.y.z. You have to dedicate a large number of ports at your firewall to make the keyspace large and those ports cannot be used for outgoing connections. If you aren't running a NAT firewall this may be impossible to implent. It's susceptible to internet weather. Dropped packet can cause the authentication to fail by timing out. The sequence order of knocks may not be available which really weakens your "passwords". Remember: There is no guarentee of the order in which packets delivered on the internet are received or processed at their destination. This makes sequencing difficult. If you have to throw out sequencing "abcde", "bacde", "abdec" and all other sequences of the letters "edcba" become the same password. Without sequencing this is not secure. But if you can implement with sequencing, a wide port range and a length of at least 8 knocks you could get a pretty big keyspace. Even after all that I think there are at least two better ways to do this:

1. IPSEC or FreeS/WAN - If you build an IPSEC tunnel between the two machines each packet is authenticated and it's reasonably safe to allow the "external" box to hit the ports on your internal side. Even ports that are closed on the outside. The overhead for using IPSec is approximately 4ms of latency if the machines doing the work are Pentium 100's or better. Also with FreeS/WAN you can use Opportunistic Encryption to set this up automatically between two boxes with dynamic IP's.

2. Create a small set of programs to do certificate based authentication using routines from the OpenSSL Engine. One program would be a small (< 1000 lines C) program to send a challenge to anyone who opened it's TCP port. This program would not run as root. It would handshake challenges to the second program, a local verification client, via the filesystem. This client would verify that the challenge had been answered correctly using digital certificates and take appropriate action. If it's not obvious the TCP listener runs unprivileged on an unprivileged port. It could be chroot jailed for further security. In any case that I can think of verification program would need to run with escalated privileges.

Problems: With IPSEC or FreeS/WAN you have to rely on a large amount of code that it is difficult to read and verify. This is also kernel code so if there is a bug in it someone really owns your box. Still, I think that the IPSEC implementations in ((Open|Free)BSD)|Linux are good enough that I trust and use them. Configuration is moderatly difficult but in the most simple cases maintenance is easy. With the two part cerificate verification daemons you have to build and run a Certificate Authority. The pieces can be built in a secure fashion that stands up the Cheswick and Bellovin's "Lunch time read test". The internal piece is more difficult because it has to has to rely on the openssl libraries but it still would follow good practices and do heavy checks on it's input before either sending bits to openssl or taking any actions.

--Ecks

While this isn't bad there are better ways to secure your ports. Firstly many are calling this security through obscurity when it's really just another layer of password protection with knocks on ports substituted for a text string.

It does have problems. It doesn't use much information and it does not provide authentication. I.e. when someone successfully "authenticates" you only know that someone knocked on the ports in the right sequence from machine w.x.y.z. You have to dedicate a large number of ports at your firewall to make the keyspace large and those ports cannot be used for outgoing connections. If you aren't running a NAT firewall this may be impossible to implent. It's susceptible to internet weather. Dropped packet can cause the authentication to fail by timing out. The sequence order of knocks may not be available which really weakens your "passwords". Remember: There is no guarentee of the order in which packets delivered on the internet are received or processed at their destination. This makes sequencing difficult. If you have to throw out sequencing "abcde", "bacde", "abdec" and all other sequences of the letters "edcba" become the same password. Without sequencing this is not secure. But if you can implement with sequencing, a wide port range and a length of at least 8 knocks you could get a pretty big keyspace. Even after all that I think there are at least two better ways to do this:

1. IPSEC or FreeS/WAN - If you build an IPSEC tunnel between the two machines each packet is authenticated and it's reasonably safe to allow the "external" box to hit the ports on your internal side. Even ports that are closed on the outside. The overhead for using IPSec is approximately 4ms of latency if the machines doing the work are Pentium 100's or better. Also with FreeS/WAN you can use Opportunistic Encryption to set this up automatically between two boxes with dynamic IP's.

2. Create a small set of programs to do certificate based authentication using routines from the OpenSSL Engine. One program would be a small (< 1000 lines C) program to send a challenge to anyone who opened it's TCP port. This program would not run as root. It would handshake challenges to the second program, a local verification client, via the filesystem. This client would verify that the challenge had been answered correctly using digital certificates and take appropriate action. If it's not obvious the TCP listener runs unprivileged on an unprivileged port. It could be chroot jailed for further security. In any case that I can think of verification program would need to run with escalated privileges.

Problems: With IPSEC or FreeS/WAN you have to rely on a large amount of code that it is difficult to read and verify. This is also kernel code so if there is a bug in it someone really owns your box. Still, I think that the IPSEC implementations in ((Open|Free)BSD)|Linux are good enough that I trust and use them. Configuration is moderatly difficult but in the most simple cases maintenance is easy. With the two part cerificate verification daemons you have to build and run a Certificate Authority. The pieces can be built in a secure fashion that stands up the Cheswick and Bellovin's "Lunch time read test". The internal piece is more difficult because it has to has to rely on the openssl libraries but it still would follow good practices and do heavy checks on it's input before either sending bits to openssl or taking any actions.

--Ecks

why is this so hard ?

I'll take a few stabs at answering that... (not a crypto person, just an amateur)

1) man-in-the-middle attack - in order to transmit the public key for encrypting the content (well, to encrypt a symetrical key which is then used to encrypt the content), you need to make sure that the key you get is actually the key for the entity that you're talking to. If the attacker in the middle can fool you into thinking that their public key is the proper one, everything you transmit is decrypted by the attacker who then chooses what to send on to the destination. MITM attacks are sorta what quantum-crypto is being designed for.

So you need a secure way of getting public keys for particular machines... why not use DNS? Well, that's what FreeS/WAN uses, except that there are issues with the security of DNS transactions that would allow MITM attacks.

Or you can use a PKI (kerberos) server to exchange keys, but PKI has the downside of being centralized (also issues with scaling of certificate-revocation-lists, etc.). Microsoft's OSs support kerberos, but do it in a not-quite-standard way IIRC.

2) Goverments will probably have fits once IPSec is widespread and their carnivore / echelon systems become useless. In fact, they'll probably outlaw it, or require easily-broken algorithms, or other restrictions. When encryption is outlawed, only criminals will have encryption... or some quote to that effect.

OK, but the parent post was suggesting that the VoIP providers would be the location of the tap. If the ISP has to be involved, it's a little more difficult (but not impossible).

Time for encryption, then. I already have one machine configured (at work) with FreeS/WAN's Opportunistic Encryption, running Full Opportunism

OK, but the parent post was suggesting that the VoIP providers would be the location of the tap. If the ISP has to be involved, it's a little more difficult (but not impossible).

Time for encryption, then. I already have one machine configured (at work) with FreeS/WAN's Opportunistic Encryption, running Full Opportunism

...for the common man like STunnel, FreeSWAN, or OpenVPN, how long can it be before people are just using private networks between family and friends at home to do IM, P2P or even Windows File Sharing? I've moved in this direction already with my family and friends. All it took was a little of my time to set up SSH clients with Local and Remote forwards that my family and friends initiate connection to my server with. Then they just access the Jabber server I run or, the internal mail server using IMAP, or the recipe database I've created, etc... Since some of my friends and family are Windows bound, I've been able to get them to use the Exodus client for Jabber with cygwin SSH to communicate with me. We even share RDP and VNC sessions. So... what does this have to do with the article? I would argue that there are a good number of people out there doing more than just IM, P2P or web browsing and they are probably doing it via tunneling. It can't be long before this becomes a part of the OS (even for Windows) to allow people to share data in new and very secure/private ways. It's done wonders for the support I offer my friends and family too...

Got some more good info on this that I thought I'd share back in case anyone else is interested. Basically if the VPN is relying on AH (authentication headers) instead of ESP then NAT becomes a problem. Good docs on this are available at the FreeS/WAN project

Of course, the author of that article went on to write CIPE, which is one of the problem protocols under discussion.

I use freeswan IPsec for securing wifi. The biggest problem with IPsec is that it suffers from "committee bloat" and is very complicated to use. Freeswan partially mitigates this complexity by implementing only a narrow subset of the RFCs (in fact, it is not even RFC compliant, because they deliberately removed some required features that might compromise security).

The good thing about IPsec, and freeswan in particular, is that they were openly developed with actual expert input and nobody has yet cast any doubt on the security of either.

FreeS/WAN

The only available free-software SSL telnet implementations all use openssl, or its predecessor SSLeay (please correct me if I'm wrong; I would love to learn about other options). This SSL library has had numerous security updates in the past. I would hardly call this record unbeatable.

I use telnet over freeswan IPsec, and I like this combination very much, but no matter what you do, you have to be on your toes.

If you have control over your own DNS, mail server, etc, now is the time to set up opportunistic encryption on your server.

• The Dutch SECREG
  
• Opportunistic Encryption
  
• My OpenOffice or PowerPoint presentation on deplying DNSSEC and OE.
  

DNSSEC is not vapourware. It will happen, and you want it to happen. Think about VOIP using the ENUM dnszone without DNSSEC. Do you WANT your phonecalls to be hijacked?

Whining about this is almost as bad as the tool that got kicked off a British Airways flight for wearing a button that said "Suspected Terrorist."

John Gilmore has done more for personal freedoms and liberties on the net than anyone you know. He founded or helped found the EFF, the "alt" newsgroups, the Cypherpunks, and Cygnus Support, the first company that showed that you could make money supporting open source software. Cygnus was later bought by Red Hat for umpteen millions of dollars, but Gilmore was already rich, having been one of the first employees at Sun Microsystems.

He has steadily plowed his money back into causes designed to promote freedom online and in the physical world. He has funded the FreeS/Wan project designed to provide automatic link-based encryption. He's also funded efforts to add security to the DNS. He provided the money for the machine that proved once and for all that DES was insecure. He is presently suing the government over travel restrictions.

As for the button incident, his point is that we are all being treated as suspected terrorists under the current regulations. As long as people put up with that without a protest, nothing is going to change. We should all be grateful that someone with Gilmore's credentials and financial strength is doing something about the increasingly harsh restrictions that all of us face as the government cracks down.

What the world really needs is opportunistic IPSec.

The "obvious" answer would have been to use FreeS/WAN or similar to set up an IPSEC tunnel to your wired network and be done with it. Windows supports IPSEC as well, and it seems like it would solve most of your problems. Am I missing something?

Encrypt. No more port blocks, no more selective service degradation, no more broken transparent proxies.

The real problem is home access - as Hugh Daniel puts it, If you're a NAT on the Net, you're NOT on the Net." In particular, you're dependent on your ISP's firewalls for email, web, and general IP access to the real world, and greatly restricted in your ability to provide information services, especially anything your ISP isn't technically competent at, and you're subject to any filtering or censorship your ISP might do. The canonical example is the "Great Firewall Of China", which
tries to prevent Chinese residents from seeing anything about Falun Gong or other forms of thoughtcrime.

It's true that Asia's APNIC got a lot less of the address space than the US did, and they may need some more before the Great IPv6 Renumbering happens. According to IANA's List of IPv4 Address Space Assignments, more than half the Class A space is unused (either never assigned or returned by public-spirited organizations that are using newer technology such as CIDR.) Class B is probably the tightest, though supernets of Class C space took off lots of the pressure. IANA is hoarding the Class A space, and maybe this will push us toward IPv6 a bit faster.

ICANN was actively discouraging IPv6 use a couple of years ago (I haven't checked up on their evil plans lately...) Their method was to declare that they were going to charge $2500 for a /48, which is the smallest generally-allocated block of IPv6 space available - so if you wanted to own your own space, it was going to cost you. I suspect part of the reason was because they wanted the money, of course, and part of it was because they didn't want to lose control over a major chokepoint of the net, but also there's the more legitimate issue that deciding the right way to restructure routing for the future shape of the internet is going to be pretty difficult, and they'd rather delay the existence of working code in order to get rough consensus first.

Note that WaveSEC is NOT a replacement for end-to-end security. All it does is protect you from wireless eavesdroppers. If you are using WaveSEC or end-to-end IPsec for all your network connections, you don't need WAVEsec.

Almost no home users have control of their reverse DNS (and most of those who do don't know how to configure it).

This kind of "hope nobody does a man-in-the-middle attack when i connect for the first time" thing has been done before (perhaps better, juding by the brief description) in SSH Sentinel.

FreeS/WAN's idea is a good one, DNS is just a bad way to make it happen currently. Maybe there should be a separate simple key exchange protocol for this (based on JFK perhaps?)

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:


"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 is from 1999 and there does not seem to be any updated information.

Adi Gadwale.

Maybe not interesting to you, but to most of the people out there - getting 1.5MBit on a low-end machine is far more than they could have asked for. Move up the ladder to a faster system, and you can push much more than that (for example. you can push 45Mbit/sec with a 1.2Ghz Pentium using FreeS/WAN - this is the equivalent of a fully loaded T3, or 28 fully loaded T1's). Could you get gigabit DES3 out of a 4 way xeon? Maybe...

Regarding a webserver only dealing with 1Mbit/sec of traffic - yes I believe this is all you need in many cases. You have to remember that many of the sites out there sit behind connections that run at or slower than T1's (which are 1.544Mbit/sec connections). If you have the money to pay a monthly bill that supports something at or faster than a T3, I'm sure you have the money to go out and either purchase a hardware crypto card (ballpark they run anywhere from $300 to $1000) that works with FreeS/WAN - or to just get your hands on a dedicated router that does all of the IPSEC for you. Afterall, T3's usually cost anywhere from $15,000 to $25,000 per month. If you start talking about gigabit (ie: OC48) - well, now you're looking at several hundred-thousand dollars a month. Overall, the cost of a crypto card is a drop in the bucket, even if you had to pay someone a few thousand to add the support to FreeS/WAN.

On a second note - why would a webserver be running IPSEC anyway? SSL is much better suited for the task.

SSH will only carry TCP traffic. If you need to encrypt anything involving UDP or ICMP (or anything else for that matter), you cannot use SSH to get the job done, except by adding on more clunkiness in the form of things that will encapsulate connectionless protocols within TCP sessions. At that point, you're no longer reaping the benefits of simplicity that come from using something like stunnel, and it's better to bite the bullet and become adept with VPNs (check out FreeS/WAN). On the upside, once you have VPN expertise in hand, you open up a new world of options for other things as well.

FreeS/WAN may not be _The Best_, but it's darn good enough:
I have a system where 12 sizable offices come into a FreeS/WAN router via a 1.5Mbit link, and the VPN moves on average 1Mbit/sec between these offices (sometimes peaks to 1.5Mbit). The VPN router that all 12 networks point to is a Pentium 166 w/ 64MB of ram, the router's been up for over 6 months (an office move required a shutdown 6 months ago), and the VPN only adds around 5 to 10 ms of latency to the connection. Heck, I get better network performance out of this setup, than my old Cisco's did running point-to-point frame-relay.

The FreeS/WAN product can also offload the crypto tasks to hardware devices when really necessary.

So Gilmore and his crew have been giving out lights for a couple of years that with stickers saying "Linux Freeswan.org" on them, originally in colors and later in white LED when that came out. By now they'd like you to buy your own Photon lights (:-), but in the crypto-geek community they're fairly common keychain accessories. Aside from using them as blinky-light toys, I've found them useful for looking inside and under things, repairing cars in the dark, etc., and the keychain size means I've always got one with me.

So Gilmore and his crew have been giving out lights for a couple of years that with stickers saying "Linux Freeswan.org" on them, originally in colors and later in white LED when that came out. By now they'd like you to buy your own Photon lights (:-), but in the crypto-geek community they're fairly common keychain accessories. Aside from using them as blinky-light toys, I've found them useful for looking inside and under things, repairing cars in the dark, etc., and the keychain size means I've always got one with me.

I'm not trying to knock you, I'm just plugging a cool product (although I'm just a user, myself).