FreeSWAN: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Sandy Harris
(typos)
mNo edit summary
 
(24 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{subpages}}
{{subpages}}
'''FreeS/WAN''' [http://www.freeswan.org] was the original [[Linux]] implementation of the [[IPsec]] protocols. The name was based, with permission, on the [[RSA Laboratories]] trademark "S/WAN" which stands for for "secure wide area network".
'''FreeS/WAN''' [http://www.freeswan.org] was the original [[Linux]] implementation of the [[IPsec]] protocols. The name was based, with permission, on the [[RSA Laboratories]] trademark "S/WAN" which stands for '''secure wide area network'''.


It was very much a politically-motivated [[cypherpunk]] project. The overall goal was to stop widespread Internet monitoring by organisations such as the [[NSA]], the Chinese government, and others. This was to be accomplished by deploying IPsec-based [[opportunistic encryption]] very widely.
It was very much a politically-motivated cypherpunk project. The overall goal was to stop widespread Internet monitoring by organisations such as the [[NSA]], the Chinese government, and others. This was to be accomplished by deploying IPsec-based [[opportunistic encryption]] very widely.


Opportunistic encryption allows any two machines to communicate securely, without any connection-specific setup by the administrators. The administrator sets up the machines, sets policies, and puts authentication keys in [[DNS]]. Once that is done, the machines themselves build and manage the connections without further administrator input. For large networks, the saving in administrator time is enormous; with <math>n</math> machines and an approach that requires administrator to configure each connection, the work increases as <math>n</math> squared. For opportunistic encryption, it increases linearly with <math>n</math>.
Opportunistic encryption allows any two machines to communicate securely, ''without the administrators doing any setup for specific connections''. The administrator sets up the machines, sets policies, and puts authentication keys in [[DNS]]. Once that is done, the machines themselves build and manage the connections without further administrator input. The authentication keys needed for secure connection setup are in DNS so any two machines can get each other's keys from DNS and create a secure connection. This alone is secure against [[passive attack | passive eavesdroppers]]; protect the authentication data with [[DNS security]] and it is also secure against [[active attack]]ers. Members of the FreeS/WAN team wrote RFCs documenting this design.<ref>{{citation
| id = RFC4322
| author = M. Richardson & D.H. Redelmeier
| title = Opportunistic Encryption using the Internet Key Exchange (IKE)
| url = http://tools.ietf.org/html/rfc4322
| date = December 2005
}}</ref> <ref>{{citation
| id = RFC4025
| author = M. Richardson
| title = A Method for Storing IPsec Keying Material in DNS
| url = http://tools.ietf.org/html/rfc4025
| date = February 2005
}}</ref>


Even more important, for FreeS/WAN purposes, opportunistic encryption allows any two machines to communicate securely, even if their administrators have had no contact with each other. With opportunistic encryption, ''secure communication could be the default'' and a significant fraction of all Internet traffic encrypted. This may not stop a policeman who has a specific suspicion and is willing to expend effort against a specific target to get evidence. It does stop wholesale monitoring, the "Big Brother is listening" approach of a police state. Widespread [[opportunistic encryption]] would put the monitoring agencies' big antenna farms out of business, or leave them with only [[traffic analysis]] to go on. That was FreeS/WAN's goal.
With opportunistic encryption, any two machines can communicate securely, ''even if their administrators have had no contact with each other'', so secure communication can be the default and a ''significant fraction of all Internet traffic may be encrypted''. This stops wholesale monitoring, the "Big Brother is listening" approach of a police state. Widespread [[opportunistic encryption]] would put the monitoring agencies' big antenna farms out of business, or leave them with only traffic analysis to go on. That was FreeS/WAN's goal.


The authentication keys needed for secure connection setup are in [[DNS]]; any two machines can get each other's keys from DNS and create a secure connection. This alone is secure against [[passive attack | passive eavesdroppers]]; protect the authentication data with [[DNS security]] and it is also secure against [[active attack]]ers. See RFC 4322 "Opportunistic Encryption using the Internet Key Exchange (IKE)", written by members of the FreeS/WAN team, for details.
The project hoped for a "FAX effect". A single FAX machine is not interesting, but once many businesses have them, getting one becomes quite desirable. If nearly everyone uses them, having one may become a requirement for doing business. FreeS/WAN hoped that opportunistic encryption could spread in the same way, eventually becoming a normal part of Internet practice. At that point, a significant fraction of Internet traffic &mdash; ideally, nearly all of the traffic &mdash; would be encrypted and monitoring the net would be extremely difficult.


Project leader was activist and [[Electronic Frontier Foundation]] [http://www.eff.org] co-founder [[John Gilmore]] [http://www.toad.com/gnu/]. Technical lead was Canadian Unix guru [[Henry Spencer]] [http://www.giganews.com/usenet-history/spencer.html].
The goal was to block police states, not to stop policemen. A policeman who has a specific suspicion and is willing to expend effort against a specific target to get evidence might get a court order to force someone to reveal that evidence, or get a search warrant, or bug the target's office, or even break into a network to gather evidence. FreeS/WAN did not attempt to prevent that, only wholesale monitoring.
 
Project leader was activist and [[Electronic Frontier Foundation]] co-founder [[John Gilmore]]. The technical lead for most of the project was Canadian Unix guru [[Henry Spencer]]. Later on, [[Michael Richardson]] took over.


The project refused to implement weak [[cryptography]], even where the RFCs required it. Their position was that the RFCs had unfortunately been subverted into including weak methods, but there was still no excuse for actually implementing those. Among the things rejected were null encryption, single [[DES]], and [[IPsec#Diffie-Hellman_key_agreement | Oakley Group 1]]. This did not generally lead to interoperation problems, even though those were the only required algorithms in the RFCs. Almost everyone implemented the more secure [[Triple DES]] and groups two and five, so almost everyone could talk to FreeS/WAN. Some users wanted single DES; the project explicitly refused to provide any assistance for that.
The project refused to implement weak [[cryptography]], even where the RFCs required it. Their position was that the RFCs had unfortunately been subverted into including weak methods, but there was still no excuse for actually implementing those. Among the things rejected were null encryption, single [[DES]], and [[IPsec#Diffie-Hellman_key_agreement | Oakley Group 1]]. This did not generally lead to interoperation problems, even though those were the only required algorithms in the RFCs. Almost everyone implemented the more secure [[Triple DES]] and groups two and five, so almost everyone could talk to FreeS/WAN. Some users wanted single DES; the project explicitly refused to provide any assistance for that.
Line 27: Line 41:
  | date = 1999 }}</ref> documents a large FreeS/WAN deployment at AT&T Laboratories.
  | date = 1999 }}</ref> documents a large FreeS/WAN deployment at AT&T Laboratories.


The FreeS/WAN project shut down in 2002, without having achieved the goal of making [[Opportunistic encryption]] widespread.
The FreeS/WAN project shut down in 2003, without having achieved the goal of making [[Opportunistic encryption]] widespread. As of early 2010, however, the [http://www.freeswan.org web site] is still up. It has complete system documentation.


Two descendants exist, [http://www.strongswan.org/ StrongSWAN] and [http://www.openswan.org/ OpenSWAN].
Two descendants exist, [http://www.strongswan.org/ StrongSWAN] and [http://www.openswan.org/ OpenSWAN].
FreeS/WAN's main technical writer is now a Citizendium [[User:Sandy_Harris |author]], and has [[User_talk:Sandy_Harris/Permission| permission]] to reuse FreeS/WAN material here.


==References==
==References==
{{reflist|2}}
{{reflist|2}}[[Category:Suggestion Bot Tag]]

Latest revision as of 16:01, 18 August 2024

This article is a stub and thus not approved.
Main Article
Discussion
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
 
This editable Main Article is under development and subject to a disclaimer.

FreeS/WAN [1] was the original Linux implementation of the IPsec protocols. The name was based, with permission, on the RSA Laboratories trademark "S/WAN" which stands for secure wide area network.

It was very much a politically-motivated cypherpunk project. The overall goal was to stop widespread Internet monitoring by organisations such as the NSA, the Chinese government, and others. This was to be accomplished by deploying IPsec-based opportunistic encryption very widely.

Opportunistic encryption allows any two machines to communicate securely, without the administrators doing any setup for specific connections. The administrator sets up the machines, sets policies, and puts authentication keys in DNS. Once that is done, the machines themselves build and manage the connections without further administrator input. The authentication keys needed for secure connection setup are in DNS so any two machines can get each other's keys from DNS and create a secure connection. This alone is secure against passive eavesdroppers; protect the authentication data with DNS security and it is also secure against active attackers. Members of the FreeS/WAN team wrote RFCs documenting this design.[1] [2]

With opportunistic encryption, any two machines can communicate securely, even if their administrators have had no contact with each other, so secure communication can be the default and a significant fraction of all Internet traffic may be encrypted. This stops wholesale monitoring, the "Big Brother is listening" approach of a police state. Widespread opportunistic encryption would put the monitoring agencies' big antenna farms out of business, or leave them with only traffic analysis to go on. That was FreeS/WAN's goal.

The project hoped for a "FAX effect". A single FAX machine is not interesting, but once many businesses have them, getting one becomes quite desirable. If nearly everyone uses them, having one may become a requirement for doing business. FreeS/WAN hoped that opportunistic encryption could spread in the same way, eventually becoming a normal part of Internet practice. At that point, a significant fraction of Internet traffic — ideally, nearly all of the traffic — would be encrypted and monitoring the net would be extremely difficult.

The goal was to block police states, not to stop policemen. A policeman who has a specific suspicion and is willing to expend effort against a specific target to get evidence might get a court order to force someone to reveal that evidence, or get a search warrant, or bug the target's office, or even break into a network to gather evidence. FreeS/WAN did not attempt to prevent that, only wholesale monitoring.

Project leader was activist and Electronic Frontier Foundation co-founder John Gilmore. The technical lead for most of the project was Canadian Unix guru Henry Spencer. Later on, Michael Richardson took over.

The project refused to implement weak cryptography, even where the RFCs required it. Their position was that the RFCs had unfortunately been subverted into including weak methods, but there was still no excuse for actually implementing those. Among the things rejected were null encryption, single DES, and Oakley Group 1. This did not generally lead to interoperation problems, even though those were the only required algorithms in the RFCs. Almost everyone implemented the more secure Triple DES and groups two and five, so almost everyone could talk to FreeS/WAN. Some users wanted single DES; the project explicitly refused to provide any assistance for that.

The project also refused to expend effort on adding features that did not lead toward the main goal, wide deployment of Opportunistic encryption. Building a general-purpose IPsec implementation for Linux was always seen as a byproduct of work toward that main goal — perhaps an interesting and important byproduct, but still a byproduct. Adding things like IPv6 support or authentication using X.509 certificates was seen as a distraction from the main work. Users did add these and some of their work was incorporated into the main FreeS/WAN distribution.

All work was done in Canada by Canadians to avoid US export laws. To ensure that it remained free of those laws, the project would not accept even a one-line bug fix from an American resident or citizen.

Later the Linux kernel team included a different IPsec implementation — one that Americans could contribute to and that was more amenable to adding features — in the kernel, and added KAME-based tools at the user level. Most current Linux distributions include those.

The "Moat" paper [3] documents a large FreeS/WAN deployment at AT&T Laboratories.

The FreeS/WAN project shut down in 2003, without having achieved the goal of making Opportunistic encryption widespread. As of early 2010, however, the web site is still up. It has complete system documentation.

Two descendants exist, StrongSWAN and OpenSWAN.

References

  1. M. Richardson & D.H. Redelmeier (December 2005), Opportunistic Encryption using the Internet Key Exchange (IKE), RFC4322
  2. M. Richardson (February 2005), A Method for Storing IPsec Keying Material in DNS, RFC4025
  3. John S. Denker, Steven M. Bellovin, Hugh Daniel, Nancy L. Mintz, Tom Killian & Mark A. Plotnick (1999). Moat: A virtual private network appliance and service platform.