PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information.PDF generated at: Fri, 11 Oct 2013 04:17:17 UTC

VPN CommunicationProtocols and FreeApplications

ContentsArticles

Virtual private network 1Secure Socket Tunneling Protocol 8IPsec 10Layer 2 Tunneling Protocol 18L2TPv3 24Point-to-Point Tunneling Protocol 26Split tunneling 29Transport Layer Security 31Social VPN 54OpenVPN 56N2n 61Openswan 62StrongSwan 63Tcpcrypt 66Tinc (protocol) 67Cloudvpn 68

ReferencesArticle Sources and Contributors 69Image Sources, Licenses and Contributors 71

Article LicensesLicense 72

Virtual private network 1

Virtual private network

VPN connectivity overview

A virtual private network (VPN) extends aprivate network across a public network, such asthe Internet. It enables a computer to send andreceive data across shared or public networks as ifit were directly connected to the private network,while benefiting from the functionality, securityand management policies of the private network.[1]

This is done by establishing a virtual point-to-pointconnection through the use of dedicatedconnections, encryption, or a combination of thetwo.

A VPN connection across the Internet is similar toa wide area network (WAN) link between the sites.From a user perspective, the extended networkresources are accessed in the same way as resources available from the private network.

VPNs allow employees to securely access their company's intranet while traveling outside the office. Similarly,VPNs securely and cost-effectively connect geographically disparate offices of an organization, creating onecohesive virtual network. VPN technology is also used by ordinary Internet users to connect to proxy servers for thepurpose of protecting one's identity.

TypesEarly data networks allowed VPN-style remote connectivity through dial-up modems or through leased lineconnections utilizing Frame Relay and Asynchronous Transfer Mode (ATM) virtual circuits, provisioned through anetwork owned and operated by telecommunication carriers. These networks are not considered true VPNs becausethey passively secure the data being transmitted by the creation of logical data streams.[2] They have given way toVPNs based on IP and IP/Multiprotocol Label Switching Networks (MPLS), due to significant cost-reductions andincreased bandwidth[3] provided by new technologies such as Digital Subscriber Line (DSL)[4] and fiber-opticnetworks.VPNs can be either remote-access (connecting an individual computer to a network) or site-to-site (connecting twonetworks together). In a corporate setting, remote-access VPNs allow employees to access their company's intranetfrom home or while traveling outside the office, and site-to-site VPNs allow employees in geographically disparateoffices to share one cohesive virtual network. A VPN can also be used to interconnect two similar networks over adissimilar middle network; for example, two IPv6 networks over an IPv4 network.VPN systems may be classified by:• the protocols used to tunnel the traffic.•• the tunnel's termination point location, e.g., on the customer edge or network-provider edge.•• whether they offer site-to-site or remote-access connectivity.•• the levels of security provided.• the OSI layer they present to the connecting network, such as Layer 2 circuits or Layer 3 network connectivity.

Virtual private network 2

Security mechanismsTo prevent disclosure of private information, VPNs typically allow only authenticated remote access and make useof encryption techniques.VPNs provide security by the use of tunneling protocols and through security procedures such as encryption. TheVPN security model provides:• confidentiality such that even if the network traffic is sniffed at the packet level (see network sniffer and Deep

packet inspection), an attacker would only see encrypted data• sender authentication to prevent unauthorized users from accessing the VPN.• message integrity to detect any instances of tampering with transmitted messagesSecure VPN protocols include the following:• Internet Protocol Security (IPsec) as initially developed by the Internet Engineering Task Force (IETF) for IPv6,

which was required in all standards-compliant implementations of IPv6 before RFC 6434 made it only arecommendation.[5] This standards-based security protocol is also widely used with IPv4 and the Layer 2Tunneling Protocol. Its design meets most security goals: authentication, integrity, and confidentiality. IPsec usesencryption, encapsulating an IP packet inside an IPsec packet. De-encapsulation happens at the end of the tunnel,where the original IP packet is decrypted and forwarded to its intended destination.

• Transport Layer Security (SSL/TLS) can tunnel an entire network's traffic (as it does in the OpenVPN project) orsecure an individual connection. A number of vendors provide remote-access VPN capabilities through SSL. AnSSL VPN can connect from locations where IPsec runs into trouble with Network Address Translation andfirewall rules.

• Datagram Transport Layer Security (DTLS) - used in Cisco AnyConnect VPN and in OpenConnect VPN to solvethe issues SSL/TLS has with tunneling over UDP.

• Microsoft Point-to-Point Encryption (MPPE) works with the Point-to-Point Tunneling Protocol and in severalcompatible implementations on other platforms.

• Microsoft Secure Socket Tunneling Protocol (SSTP) tunnels Point-to-Point Protocol (PPP) or Layer 2 TunnelingProtocol traffic through an SSL 3.0 channel. (SSTP was introduced in Windows Server 2008 and in WindowsVista Service Pack 1.)

• Multi Path Virtual Private Network (MPVPN). Ragula Systems Development Company owns the registeredtrademark "MPVPN".[6]

• Secure Shell (SSH) VPN - OpenSSH offers VPN tunneling (distinct from port forwarding) to secure remoteconnections to a network or to inter-network links. OpenSSH server provides a limited number of concurrenttunnels. The VPN feature itself does not support personal authentication.[7][8][9]

AuthenticationTunnel endpoints must authenticate before secure VPN tunnels can be established.User-created remote-access VPNs may use passwords, biometrics, two-factor authentication or other cryptographicmethods.Network-to-network tunnels often use passwords or digital certificates. They permanently store the key to allow thetunnel to establish automatically, without intervention from the user.

Virtual private network 3

Example use of a VPN tunnelThe following steps illustrate the principles of a VPN client-server interaction in simple terms.Assume a remote host with public IP address 1.2.3.4 wishes to connect to a server found inside a company network.The server has internal address 192.168.1.10 and is not reachable publicly. Before the client can reach this server, itneeds to go through a VPN server / firewall device that has public IP address 5.6.7.8 and an internal address of192.168.1.1. All data between the client and the server will need to be kept confidential, hence a secure VPN is used.1.1. The VPN client connects to a VPN server via an external network interface.2. The VPN server assigns an IP address to the VPN client from the VPN server's subnet. The client gets internal IP

address 192.168.1.50, for example, and creates a virtual network interface through which it will send encryptedpackets to the other tunnel endpoint (the device at the other end of the tunnel). (This interface also gets theaddress 192.168.1.50.)

3.3. When the VPN client wishes to communicate with the company server, it prepares a packet addressed to192.168.1.10, encrypts it and encapsulates it in an outer VPN packet, say an IPSec packet. This packet is then sentto the VPN server at IP address 5.6.7.8 over the public Internet. The inner packet is encrypted so that even ifsomeone intercepts the packet over the Internet, they cannot get any information from it. They can see that theremote host is communicating with a server/firewall, but none of the contents of the communication. The innerencrypted packet has source address 192.168.1.50 and destination address 192.168.1.10. The outer packet hassource address 1.2.3.4 and destination address 5.6.7.8.

4.4. When the packet reaches the VPN server from the Internet, the VPN server decapsulates the inner packet,decrypts it, finds the destination address to be 192.168.1.10, and forwards it to the intended server at192.168.1.10.

5. After some time, the VPN server receives a reply packet from 192.168.1.10, intended for 192.168.1.50. The VPNserver consults its routing table, and sees this packet is intended for a remote host that must go through VPN.

6.6. The VPN server encrypts this reply packet, encapsulates it in a VPN packet and sends it out over the Internet. Theinner encrypted packet has source address 192.168.1.10 and destination address 192.168.1.50. The outer VPNpacket has source address 5.6.7.8 and destination address 1.2.3.4.

7.7. The remote host receives the packet. The VPN client decapsulates the inner packet, decrypts it, and passes it tothe appropriate software at upper layers.

Overall, it is as if the remote computer and company server are on the same 192.168.1.0/24 network.

RoutingTunneling protocols can operate in a point-to-point network topology that would theoretically not be considered aVPN, because a VPN by definition is expected to support arbitrary and changing sets of network nodes. But sincemost router implementations support a software-defined tunnel interface, customer-provisioned VPNs often aresimply defined tunnels running conventional routing protocols.

Provider-provisioned VPN building-blocksDepending on whether a provider-provisioned VPN (PPVPN)Wikipedia:Please clarify operates in layer 2 or layer 3,the building blocks described below may be L2 only, L3 only, or combine them both. Multiprotocol label switching(MPLS) functionality blurs the L2-L3 identity.[citation needed]Wikipedia:No original researchRFC 4026 generalized the following terms to cover L2 and L3 VPNs, but they were introduced in RFC 2547. Moreinformation on the devices below can also be found in Lewis, Cisco Press.Customer (C) devicesA device that is within a customer's network and not directly connected to the service provider's network. C devicesare not aware of the VPN.

Virtual private network 4

Customer Edge device (CE)A device at the edge of the customer's network which provides access to the PPVPN. Sometimes it's just ademarcation point between provider and customer responsibility. Other providers allow customers to configure it.Provider edge device (PE)A PE is a device, or set of devices, at the edge of the provider network which connects to customer networks throughCE devices and presents the provider's view of the customer site. PEs are aware of the VPNs that connect throughthem, and maintain VPN state.Provider device (P)A P device operates inside the provider's core network and does not directly interface to any customer endpoint. Itmight, for example, provide routing for many provider-operated tunnels that belong to different customers' PPVPNs.While the P device is a key part of implementing PPVPNs, it is not itself VPN-aware and does not maintain VPNstate. Its principal role is allowing the service provider to scale its PPVPN offerings, for example, by acting as anaggregation point for multiple PEs. P-to-P connections, in such a role, often are high-capacity optical links betweenmajor locations of providers.

User-visible PPVPN servicesThis section deals with the types of VPN considered in the IETF.

OSI Layer 2 servicesVirtual LANA Layer 2 technique that allows for the coexistence of multiple LAN broadcast domains, interconnected via trunksusing the IEEE 802.1Q trunking protocol. Other trunking protocols have been used but have become obsolete,including Inter-Switch Link (ISL), IEEE 802.10 (originally a security protocol but a subset was introduced fortrunking), and ATM LAN Emulation (LANE).Virtual private LAN service (VPLS)Developed by IEEE, VLANs allow multiple tagged LANs to share common trunking. VLANs frequently compriseonly customer-owned facilities. Whereas VPLS as described in the above section (OSI Layer 1 services) supportsemulation of both point-to-point and point-to-multipoint topologies, the method discussed here extends Layer 2technologies such as 802.1d and 802.1q LAN trunking to run over transports such as Metro Ethernet.As used in this context, a VPLS is a Layer 2 PPVPN, rather than a private line, emulating the full functionality of atraditional local area network (LAN). From a user standpoint, a VPLS makes it possible to interconnect several LANsegments over a packet-switched, or optical, provider core; a core transparent to the user, making the remote LANsegments behave as one single LAN.In a VPLS, the provider network emulates a learning bridge, which optionally may include VLAN service.Pseudo wire (PW)PW is similar to VPWS, but it can provide different L2 protocols at both ends. Typically, its interface is a WANprotocol such as Asynchronous Transfer Mode or Frame Relay. In contrast, when aiming to provide the appearanceof a LAN contiguous between two or more locations, the Virtual Private LAN service or IPLS would be appropriate.IP-only LAN-like service (IPLS)A subset of VPLS, the CE devices must have L3 capabilities; the IPLS presents packets rather than frames. It maysupport IPv4 or IPv6.

Virtual private network 5

OSI Layer 3 PPVPN architecturesThis section discusses the main architectures for PPVPNs, one where the PE disambiguates duplicate addresses in asingle routing instance, and the other, virtual router, in which the PE contains a virtual router instance per VPN. Theformer approach, and its variants, have gained the most attention.One of the challenges of PPVPNs involves different customers using the same address space, especially the IPv4private address space.[10] The provider must be able to disambiguate overlapping addresses in the multiplecustomers' PPVPNs.BGP/MPLS PPVPNIn the method defined by RFC 2547, BGP extensions advertise routes in the IPv4 VPN address family, which are ofthe form of 12-byte strings, beginning with an 8-byte Route Distinguisher (RD) and ending with a 4-byte IPv4address. RDs disambiguate otherwise duplicate addresses in the same PE.PEs understand the topology of each VPN, which are interconnected with MPLS tunnels, either directly or via Prouters. In MPLS terminology, the P routers are Label Switch Routers without awareness of VPNs.Virtual router PPVPNThe Virtual Router architecture,[11][12] as opposed to BGP/MPLS techniques, requires no modification to existingrouting protocols such as BGP. By the provisioning of logically independent routing domains, the customeroperating a VPN is completely responsible for the address space. In the various MPLS tunnels, the different PPVPNsare disambiguated by their label, but do not need routing distinguishers.

Plaintext tunnelsSome virtual networks may not use encryption to protect the data contents. While VPNs often provide security, anunencrypted overlay network does not neatly fit within the secure or trusted categorization. For example a tunnel setup between two hosts that used Generic Routing Encapsulation (GRE) would in fact be a virtual private network, butneither secure nor trusted.Besides the GRE example above, native plaintext tunneling protocols include Layer 2 Tunneling Protocol (L2TP)when it is set up without IPsec and Point-to-Point Tunneling Protocol (PPTP) or Microsoft Point-to-Point Encryption(MPPE).

Trusted delivery networksTrusted VPNs do not use cryptographic tunneling, and instead rely on the security of a single provider's network toprotect the traffic.• Multi-Protocol Label Switching (MPLS) often overlays VPNs, often with quality-of-service control over a trusted

delivery network.• Layer 2 Tunneling Protocol (L2TP)[13] which is a standards-based replacement, and a compromise taking the

good features from each, for two proprietary VPN protocols: Cisco's Layer 2 Forwarding (L2F)[14] (obsolete as of2009[15]) and Microsoft's Point-to-Point Tunneling Protocol (PPTP).[16]

From the security standpoint, VPNs either trust the underlying delivery network, or must enforce security withmechanisms in the VPN itself. Unless the trusted delivery network runs among physically secure sites only, bothtrusted and secure models need an authentication mechanism for users to gain access to the VPN.

Virtual private network 6

VPNs in mobile environmentsMobile VPNs are used in a setting where an endpoint of the VPN is not fixed to a single IP address, but insteadroams across various networks such as data networks from cellular carriers or between multiple Wi-Fi accesspoints.[17] Mobile VPNs have been widely used in public safety, where they give law enforcement officers access tomission-critical applications, such as computer-assisted dispatch and criminal databases, while they travel betweendifferent subnets of a mobile network.[18] They are also used in field service management and by healthcareorganizations,[19] among other industries.Increasingly, mobile VPNs are being adopted by mobile professionals who need reliable connections. They are usedfor roaming seamlessly across networks and in and out of wireless-coverage areas without losing applicationsessions or dropping the secure VPN session. A conventional VPN cannot survive such events because the networktunnel is disrupted, causing applications to disconnect, time out, or fail, or even cause the computing device itself tocrash.Instead of logically tying the endpoint of the network tunnel to the physical IP address, each tunnel is bound to apermanently associated IP address at the device. The mobile VPN software handles the necessary networkauthentication and maintains the network sessions in a manner transparent to the application and the user. The HostIdentity Protocol (HIP), under study by the Internet Engineering Task Force, is designed to support mobility of hostsby separating the role of IP addresses for host identification from their locator functionality in an IP network. WithHIP a mobile host maintains its logical connections established via the host identity identifier while associating withdifferent IP addresses when roaming between access networks.

References[1] Mason, Andrew G. Cisco Secure Virtual Private Network. Cisco Press, 2002, p. 7[2] Cisco Systems, et al.. Internet working Technologies Handbook, Third Edition. Cisco Press, 2000, p. 232.[3] Lewis, Mark. Comparing, Designing. And Deploying VPNs. Cisco Press, 20069, p. 5[4] International Engineering Consortium. Digital Subscriber Line 2001. Intl. Engineering Consortium, 2001, p. 40.[5][5] RFC 6434, "IPv6 Node Requirements", E. Jankiewicz, J. Loughney, T. Narten (December 2011)[6] Trademark Applications and Registrations Retrieval (TARR) (http:/ / tarr. uspto. gov/ servlet/ tarr?regser=serial& entry=78063238&

action=Request+ Status)[7] OpenBSD ssh manual page, VPN section (http:/ / www. openbsd. org/ cgi-bin/ man. cgi?query=ssh#SSH-BASED+ VIRTUAL)[8] Unix Toolbox section on SSH VPN (http:/ / cb. vu/ unixtoolbox. xhtml#vpn)[9] Ubuntu SSH VPN how-to (https:/ / help. ubuntu. com/ community/ SSH_VPN)[10] Address Allocation for Private Internets (http:/ / www. ietf. org/ rfc/ rfc1918. txt), RFC 1918, Y. Rekhter et al.,February 1996[11] RFC 2917, A Core MPLS IP VPN Architecture[12][12] RFC 2918, E. Chen (September 2000)[13] Layer Two Tunneling Protocol "L2TP" (http:/ / www. ietf. org/ rfc/ rfc2661. txt), RFC 2661, W. Townsley et al.,August 1999[14] IP Based Virtual Private Networks (http:/ / www. ietf. org/ rfc/ rfc2341. txt), RFC 2341, A. Valencia et al., May 1998[15] http:/ / en. wikipedia. org/ w/ index. php?title=Virtual_private_network& action=edit[16] Point-to-Point Tunneling Protocol (PPTP) (http:/ / www. ietf. org/ rfc/ rfc2637. txt), RFC 2637, K. Hamzeh et al., July 1999[17] Phifer, Lisa. "Mobile VPN: Closing the Gap" (http:/ / searchmobilecomputing. techtarget. com/ tip/ 0,289483,sid40_gci1210989_mem1,00.

html), SearchMobileComputing.com, July 16, 2006.[18] Willett, Andy. "Solving the Computing Challenges of Mobile Officers" (http:/ / www. officer. com/ print/ Law-Enforcement-Technology/

Solving-the-Computing-Challenges-of-Mobile-Officers/ 1$30992), www.officer.com, May, 2006.[19] Cheng, Roger. "Lost Connections" (http:/ / online. wsj. com/ article/ SB119717610996418467. html), The Wall Street Journal, December

11, 2007.

Virtual private network 7

Further reading• Kelly, Sean (August 2001). "Necessity is the mother of VPN invention" (http:/ / web. archive. org/ web/

20011217153420/ http:/ / www. comnews. com/ cgi-bin/ arttop. asp?Page=c0801necessity. htm). CommunicationNews: 26–28. ISSN  0010-3632 (http:/ / www. worldcat. org/ issn/ 0010-3632). Archived from the original (http:// www. comnews. com/ cgi-bin/ arttop. asp?Page=c0801necessity. htm) on 2001-12-17.

• "VPN Buyers Guide". Communication News: 34–38. August 2001. ISSN  0010-3632 (http:/ / www. worldcat.org/ issn/ 0010-3632).

External links• JANET UK "Different Flavours of VPN: Technology and Applications" (https:/ / www. ja. net/ sites/ default/

files/ Different Flavours of VPN Technology and Applications. pdf)• Virtual Private Network Consortium - a trade association for VPN vendors (http:/ / www. vpnc. org/ )• CShip VPN-Wiki/List (http:/ / en. cship. org/ wiki/ Virtual_Private_Network)• Virtual Private Networks (http:/ / www. microsoft. com/ vpn) on Microsoft TechNet• Creating VPNs with IPsec and SSL/TLS (http:/ / www. linuxjournal. com/ article/ 9916) Linux Journal article by

Rami Rosen• curvetun (http:/ / netsniff-ng. org) a lightweight curve25519-based multiuser IP tunnel / VPN• MPLS Telecom Networks (http:/ / www. sermotelecom. co. uk/ )• Virtual Private Networks - In Depth Technical Details (http:/ / www. rawbytes. com/

virtual-private-networks-in-depth-technical-details/ )• VPN Hardware Security Module (HSM) (http:/ / www. ultra-aep. com/ solutions/ encryption)• Using VPN to bypass internet censorship (http:/ / en. flossmanuals. net/ bypassing-censorship/

ch025_what-is-vpn/ ) in How to Bypass Internet Censorship (http:/ / www. howtobypassinternetcensorship. org/ ),a FLOSS Manual, 10 March 2011, 240 pp

Secure Socket Tunneling Protocol 8

Secure Socket Tunneling ProtocolSecure Socket Tunneling Protocol (SSTP) is a form of VPN tunnel that provides a mechanism to transport PPP orL2TP traffic through an SSL 3.0 channel. SSL provides transport-level security with key-negotiation, encryption andtraffic integrity checking. The use of SSL over TCP port 443 allows SSTP to pass through virtually all firewalls andproxy servers except for authenticated web proxies.[1]

SSTP servers must be authenticated during the SSL phase. SSTP clients can optionally be authenticated during theSSL phase, and must be authenticated in the PPP phase. The use of PPP allows support for common authenticationmethods, such as EAP-TLS and MS-CHAP.SSTP is available for Linux, BSD, and Windows.[2] The Mikrotik RouterOS also includes an SSTP client and server.For Windows, SSTP is only available since version Windows Vista SP1, in RouterOS, and in SEIL since itsfirmware version 3.50. It is fully integrated with the RRAS architecture in these operating systems, allowing its usewith Winlogon or smart card authentication, remote access policies and the Windows VPN client.[3]

SSTP was intended only for remote client access, it generally does not support site-to-site VPN tunnels.[4] TheRouterOS version has no such restrictions.SSTP suffers from the same performance limitations as any other IP-over-TCP tunnel. In general, performance willbe acceptable only as long as there is sufficient excess bandwidth on the un-tunneled network link to guarantee thatthe tunneled TCP timers do not expire. If this becomes untrue, performance falls off dramatically. This is known asthe "TCP meltdown problem"[5][6]

Packet structure

HeaderThe following header structure is common to all types of SSTP packets:[7]

SSTP Header

Bit offset Bits 0–7 8–14 15 16–31

0 Version Reserved C Length

32+ Data

• Version (8 bits) – communicates and negotiates the version of SSTP that is used.• Reserved (7 bits) – reserved for future use.• C (1 bit) – Control bit indicating whether the SSTP packet represents an SSTP control packet or an SSTP data

packet. This bit is set if the SSTP packet is a control packet.• Length (16 bits) – packet length field, composed of two values: a Reserved portion and a Length portion.

• Reserved (4 bits) – reserved for future use.• Length (12 bits) – contains the length of the entire SSTP packet, including the SSTP header.

• Data (variable) – when Control bit C is set, this field contains an SSTP control message. Otherwise, the data fieldwould contain a higher level protocol. At the moment, this can only be PPP.

Secure Socket Tunneling Protocol 9

Control messageThe data field of the SSTP header contains an SSTP control message only when the header's Control bit C is set.

SSTP Control Message

Bit offset Bits 0–15 16–31

0 Message Type Attributes Count

32+ Attributes

• Message Type (16 bits) – specifies the type of SSTP control message being communicated. This dictates thenumber and types of attributes that can be carried in the SSTP control packet.

• Attributes Count (16 bits) – specifies the number of attributes appended to the SSTP control message.• Attributes (variable) – contains a list of attributes associated with the SSTP control message. The number of

attributes is specified by the Attributes Count field.

References[1] SSTP FAQ - Part 2: Client Specific (http:/ / blogs. technet. com/ b/ rrasblog/ archive/ 2007/ 01/ 17/ sstp-faq-part-2-client-specific. aspx)[2] SSTP Client Project (http:/ / sourceforge. net/ projects/ sstp-client/ )[3] SSTP Makes Secure Remote Access Easier (http:/ / biztechmagazine. com/ article. asp?item_id=377)[4] SSTP FAQ (http:/ / blogs. technet. com/ rrasblog/ archive/ 2007/ 01/ 10/ sstp-faq-part-1-generic. aspx)[5] Why TCP Over TCP Is A Bad Idea (http:/ / sites. inka. de/ bigred/ devel/ tcp-tcp. html)[6] Understanding TCP over TCP: effects of TCP tunneling on end-to-end throughput and latency (http:/ / adsabs. harvard. edu/ abs/ 2005SPIE.

6011. . 138H)[7] MS-SSTP specification (http:/ / msdn. microsoft. com/ en-us/ library/ cc247338(v=prot. 10). aspx)

External links• RRAS Technet Blog (http:/ / blogs. technet. com/ rrasblog/ archive/ tags/ SSTP/ default. aspx)• Microsoft develops new tunneling protocol (http:/ / www. techworld. com/ networking/ news/ index.

cfm?newsID=7814& pagtype=all)• How SSTP based VPN connection works (http:/ / blogs. technet. com/ rrasblog/ archive/ 2007/ 01/ 10/

how-sstp-based-vpn-connection-works. aspx)• Configuring SSTP in RouterOS (http:/ / wiki. mikrotik. com/ wiki/ SSTP)• HSC's SSTP Client for Linux (http:/ / www. hsc. fr/ ressources/ outils/ sstoper/ index. html. en)• SSTP Client for Linux (http:/ / sstp-client. sourceforge. net/ )

IPsec 10

IPsecInternet Protocol Security (IPsec) is a protocol suite for securing Internet Protocol (IP) communications byauthenticating and encrypting each IP packet of a communication session. IPsec includes protocols for establishingmutual authentication between agents at the beginning of the session and negotiation of cryptographic keys to beused during the session. IPsec can be used in protecting data flows between a pair of hosts (host-to-host), between apair of security gateways (network-to-network), or between a security gateway and a host (network-to-host).IPsec is an end-to-end security scheme operating in the Internet Layer of the Internet Protocol Suite, while someother Internet security systems in widespread use, such as Secure Sockets Layer (SSL), Transport Layer Security(TLS) and Secure Shell (SSH), operate in the upper layers of the TCP/IP model. Hence, IPsec protects anyapplication traffic across an IP network. Applications do not need to be specifically designed to use IPsec. The use ofTLS/SSL had to be designed into an application to protect the application protocols.

HistoryIn December 1993, the Software IP Encryption protocol swIPe (protocol) was developed at Columbia University andAT&T Bell Labs by John Ioannidis and others.In July 1994, Wei Xu at Trusted Information Systems continued this research which was completed successfully onthe BSDI platform after a few months. Wei quickly extended his development on to Sun OS, HP UX, and otherUNIX systems. One of the challenges was slow performance of DES and Triple DES. The software encryption wasunable to support a T1 speed under the Intel 80386 architecture. By exploring the Crypto cards from Germany, WeiXu further developed an automated device driver, known as plug-and-play today. By achieving the throughput formore than a T1s, this work made the commercial product practically feasible, that was released as a part of thewell-known Gauntlet firewall. In December 1994, it was the first time in production for securing some remote sitesbetween east and west coastal states of the United States. [citation needed]

The IETF IP Security Protocol was developed starting in 1992 at the Naval Research Laboratory as part of aDARPA-sponsored research project, with openly published drafts by 1993. ESP was originally derived from the USDepartment of Defense SP3D protocol, rather than being derived from the ISO Network-Layer Security Protocol(NLSP). The SP3D protocol specification was published by NIST, but designed by the Secure Data Network Systemproject of the US Department of Defense. AH is derived in part from previous IETF standards work forauthentication of the Simple Network Management Protocol (SNMP) version 2.IPsec is officially standardised by the Internet Engineering Task Force (IETF) in a series of Request for Commentsdocuments addressing various components and extensions. It specifies the spelling of the protocol name to be IPsec.

Internetprotocol suite

Application layer

•• DHCP•• DHCPv6•• DNS•• FTP•• HTTP•• IMAP•• IRC•• LDAP•• MGCP•• NNTP

IPsec 11

•• BGP•• NTP•• POP•• RPC•• RTP•• RTSP•• RIP•• SIP•• SMTP•• SNMP•• SOCKS•• SSH•• Telnet•• TLS/SSL•• XMPP•• more...

Transport layer

•• TCP•• UDP•• DCCP•• SCTP•• RSVP•• more...

Internet layer

•• IP•• IPv4•• IPv6

•• ICMP•• ICMPv6•• ECN•• IGMP•• IPsec•• more...

Link layer

•• ARP/InARP•• NDP•• OSPF•• Tunnels

•• L2TP•• PPP•• Media access control

•• Ethernet•• DSL•• ISDN•• FDDI

•• more...

IPsec 12

Security architectureThe IPsec suite is an open standard. IPsec uses the following protocols to perform various functions:• Authentication Headers (AH) provide connectionless integrity and data origin authentication for IP datagrams and

provides protection against replay attacks.• Encapsulating Security Payloads (ESP) provide confidentiality, data-origin authentication, connectionless

integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic-flow confidentiality.• Security Associations (SA) provide the bundle of algorithms and data that provide the parameters necessary to

AH and/or ESP operations. The Internet Security Association and Key Management Protocol (ISAKMP) providesa framework for authentication and key exchange,[1] with actual authenticated keying material provided either bymanual configuration with pre-shared keys, Internet Key Exchange (IKE and IKEv2), Kerberized InternetNegotiation of Keys (KINK), or IPSECKEY DNS records.

Authentication HeaderAuthentication Header (AH) is a member of the IPsec protocol suite. AH guarantees connectionless integrity anddata origin authentication of IP packets. Further, it can optionally protect against replay attacks by using the slidingwindow technique and discarding old packets (see below).• In IPv4, the AH protects the IP payload and all header fields of an IP datagram except for mutable fields (i.e.

those that might be altered in transit), and also IP options such as the IP Security Option (RFC-1108). Mutable(and therefore unauthenticated) IPv4 header fields are DSCP/ToS, ECN, Flags, Fragment Offset, TTL and HeaderChecksum.

• In IPv6, the AH protects the most of the IPv6 base header, AH itself, non-mutable extension headers after the AH,and the IP payload. Protection for the IPv6 header excludes the mutable fields: DSCP, ECN, Flow Label, and HopLimit.

AH operates directly on top of IP, using IP protocol number 51.The following AH packet diagram shows how an AH packet is constructed and interpreted:

Authentication Header format

Offsets Octet16

0 1 2 3

Octet16

Bit10

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

0 0 Next Header Payload Len Reserved

4 32 Security Parameters Index (SPI)

8 64 Sequence Number

C 96 Integrity Check Value (ICV)…

… …

Next Header (8 bits)Type of the next header, indicating what upper-layer protocol was protected. The value is taken from the list ofIP protocol numbers.

Payload Len (8 bits)The length of this Authentication Header in 4-octet units, minus 2. For example an AH value of 4 equals 3x(32-bit fixed-length AH fields) + 3x(32-bit ICV fields) - 2 and thus an AH value of 4 means 24 octets. Although the size is measured in 4-octet units, the length of this header needs to be a multiple of 8 octets if carried in an IPv6 packet. This restriction does not apply to an Authentication Header carried in an IPv4

IPsec 13

packet.Reserved (16 bits)

Reserved for future use (all zeroes until then).Security Parameters Index (32 bits)

Arbitrary value which is used (together with the destination IP address) to identify the security association ofthe receiving party.

Sequence Number (32 bits)A monotonic strictly increasing sequence number (incremented by 1 for every packet sent) to prevent replayattacks. When replay detection is enabled, sequence numbers are never reused, because a new securityassociation must be renegotiated before an attempt to increment the sequence number beyond its maximumvalue.

Integrity Check Value (multiple of 32 bits)Variable length check value. It may contain padding to align the field to an 8-octet boundary for IPv6, or a4-octet boundary for IPv4.

Encapsulating Security PayloadEncapsulating Security Payload (ESP) is a member of the IPsec protocol suite. In IPsec it provides originauthenticity, integrity and confidentiality protection of packets. ESP also supports encryption-only andauthentication-only configurations, but using encryption without authentication is strongly discouraged because it isinsecure. Unlike Authentication Header (AH), ESP in transport mode does not provide integrity and authenticationfor the entire IP packet. However, in Tunnel Mode, where the entire original IP packet is encapsulated with a newpacket header added, ESP protection is afforded to the whole inner IP packet (including the inner header) while theouter header (including any outer IPv4 options or IPv6 extension headers) remains unprotected. ESP operatesdirectly on top of IP, using IP protocol number 50.The following ESP packet diagram shows how an ESP packet is constructed and interpreted:

Encapsulating Security Payload format

Offsets Octet16

0 1 2 3

Octet16

Bit10

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

0 0 Security Parameters Index (SPI)

4 32 Sequence Number

8 64 Payload data

… …

… …

… … Padding (0-255 octets)

… … Pad Length Next Header

… … Integrity Check Value (ICV)…

… …

Security Parameters Index (32 bits)Arbitrary value used (together with the destination IP address) to identify the security association of thereceiving party.

IPsec 14

Sequence Number (32 bits)A monotonically increasing sequence number (incremented by 1 for every packet sent) to protect againstreplay attacks. There is a separate counter kept for every security association.

Payload data (variable)The protected contents of the original IP packet, including any data used to protect the contents (e.g. anInitialisation Vector for the cryptographic algorithm). The type of content that was protected is indicated bythe Next Header field.

Padding (0-255 octets)Padding for encryption, to extend the payload data to a size that fits the encryption's cipher block size, and toalign the next field.

Pad Length (8 bits)Size of the padding (in octets).

Next Header (8 bits)Type of the next header. The value is taken from the list of IP protocol numbers.

Integrity Check Value (multiple of 32 bits)Variable length check value. It may contain padding to align the field to an 8-octet boundary for IPv6, or a4-octet boundary for IPv4.

Security associationThe IP security architecture uses the concept of a security association as the basis for building security functions intoIP. A security association is simply the bundle of algorithms and parameters (such as keys) that is being used toencrypt and authenticate a particular flow in one direction. Therefore, in normal bi-directional traffic, the flows aresecured by a pair of security associations.Security associations are established using the Internet Security Association and Key Management Protocol(ISAKMP). ISAKMP is implemented by manual configuration with pre-shared secrets, Internet Key Exchange (IKEand IKEv2), Kerberized Internet Negotiation of Keys (KINK), and the use of IPSECKEY DNS records.[2][3] RFC5386 defines Better-Than-Nothing Security (BTNS) as an unauthenticated mode of IPsec using an extended IKEprotocol.In order to decide what protection is to be provided for an outgoing packet, IPsec uses the Security Parameter Index(SPI), an index to the security association database (SADB), along with the destination address in a packet header,which together uniquely identify a security association for that packet. A similar procedure is performed for anincoming packet, where IPsec gathers decryption and verification keys from the security association database.For multicast, a security association is provided for the group, and is duplicated across all authorized receivers of thegroup. There may be more than one security association for a group, using different SPIs, thereby allowing multiplelevels and sets of security within a group. Indeed, each sender can have multiple security associations, allowingauthentication, since a receiver can only know that someone knowing the keys sent the data. Note that the relevantstandard does not describe how the association is chosen and duplicated across the group; it is assumed that aresponsible party will have made the choice.

IPsec 15

Modes of operationIPsec can be implemented in a host-to-host transport mode, as well as in a network tunnel mode.

Transport modeIn transport mode, only the payload of the IP packet is usually encrypted and/or authenticated. The routing is intact,since the IP header is neither modified nor encrypted; however, when the authentication header is used, the IPaddresses cannot be translated, as this will invalidate the hash value. The transport and application layers are alwayssecured by hash, so they cannot be modified in any way (for example by translating the port numbers).A means to encapsulate IPsec messages for NAT traversal has been defined by RFC documents describing theNAT-T mechanism.

Tunnel modeIn tunnel mode, the entire IP packet is encrypted and/or authenticated. It is then encapsulated into a new IP packetwith a new IP header. Tunnel mode is used to create virtual private networks for network-to-networkcommunications (e.g. between routers to link sites), host-to-network communications (e.g. remote user access) andhost-to-host communications (e.g. private chat).Tunnel mode supports NAT traversal.

Cryptographic algorithmsCryptographic algorithms defined for use with IPsec include:• HMAC-SHA1 for integrity protection and authenticity.• TripleDES-CBC for confidentiality• AES-CBC for confidentiality.Refer to RFC 4835 for details.

Software implementationsIPsec support is usually implemented in the kernel with key management and ISAKMP/IKE negotiation carried outfrom user-space. The openly specified 'PF_KEY Key Management API, Version 2' is often used to enable theapplication-space key management application to update the IPsec Security Associations stored within thekernel-space IPsec implementation.[4]

Existing IPsec implementations usually include ESP, AH, and IKE version 2. Existing IPsec implementations onUNIX-like operating systems, for example Sun Solaris or Linux, usually include PF_KEY version 2.

Standards statusIPsec was developed in conjunction with IPv6 and was originally required in all standards-compliantimplementations of IPv6 before RFC 6434 made it only a recommendation.[5] IPsec is also optional for IPv4implementations but due to the slow deployment of IPv6, IPsec is most commonly used to secure IPv4 traffic.IPsec protocols were originally defined in RFC 1825 through RFC 1829, which were published in 1995. In 1998, these documents were superseded by RFC 2401 and RFC 2412 with a few incompatible engineering details, although they were conceptually identical. In addition, a mutual authentication and key exchange protocol Internet Key Exchange (IKE) was defined to create and manage security associations. In December 2005, new standards were defined in RFC 4301 and RFC 4309 which are largely a superset of the previous editions with a second version of the Internet Key Exchange standard IKEv2. These third-generation documents standardized the abbreviation of

IPsec 16

IPsec to uppercase “IP” and lowercase “sec”. “ESP” generally refers to RFC 4303, which is the most recent version ofthe specification.Since mid-2008, an IPsec Maintenance and Extensions working group is active at the IETF.[6][7]

Alleged NSA interferenceAs part of the Snowden leaks, it has been revealed that the US National Security Agency has been actively workingto "Insert vulnerabilities into commercial encryption systems, IT systems, networks, and endpoint communicationsdevices used by targets" as part of the Bullrun program. There are allegations that IPsec was a targeted encryptionsystem.The OpenBSD IPsec stack was the first implementation which was available under a permissive open source license,and was therefore copied widely. In a letter which OpenBSD lead developer Theo de Raadt received on 11 Dec 2010from Gregory Perry, it is alleged that Jason Wright and others, working for the FBI, inserted "a number of backdoorsand side channel key leaking mechanisms" into the OpenBSD crypto code. In the forwarded email from 2010, Theode Raadt does not express an official position on the validity of the claims, apart from the implicit endorsement fromforwarding the email. Note that this was published before the Snowden leaks.John Gilmore, who followed the IPsec IETF standards committee and lead a group that tried to implement IPsec, hasspeculated that the NSA sabotaged the IPsec standard. From observation, Gilmore speculates that the NSApurposefully made the standard less secure than it could have been, and unnecessarily complicated and hard todeploy, with the goal of hampering the spread of strong crypto unbreakable to the NSA. Gilmore points out that NSApersonnel participated in the IPsec IETF standards committee.

IETF documentation

Standards Track•• RFC 2403: The Use of HMAC-MD5-96 within ESP and AH•• RFC 2404: The Use of HMAC-SHA-1-96 within ESP and AH•• RFC 2405: The ESP DES-CBC Cipher Algorithm With Explicit IV•• RFC 2410: The NULL Encryption Algorithm and Its Use With IPsec•• RFC 2451: The ESP CBC-Mode Cipher Algorithms•• RFC 2857: The Use of HMAC-RIPEMD-160-96 within ESP and AH•• RFC 3526: More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)•• RFC 3947: Negotiation of NAT-Traversal in the IKE•• RFC 3948: UDP Encapsulation of IPsec ESP Packets•• RFC 4106: The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)•• RFC 4301: Security Architecture for the Internet Protocol•• RFC 4302: IP Authentication Header•• RFC 4303: IP Encapsulating Security Payload•• RFC 4304: Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet

Security Association and Key Management Protocol (ISAKMP)• RFC 4307: Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)•• RFC 4308: Cryptographic Suites for IPsec•• RFC 4309: Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload

(ESP)•• RFC 4543: The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH•• RFC 4555: IKEv2 Mobility and Multihoming Protocol (MOBIKE)•• RFC 4806: Online Certificate Status Protocol (OCSP) Extensions to IKEv2

IPsec 17

•• RFC 4835: Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP)and Authentication Header (AH)

•• RFC 4945: The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX•• RFC 5996: Internet Key Exchange Protocol Version 2 (IKEv2)

Experimental RFCs•• RFC 4478: Repeated Authentication in Internet Key Exchange (IKEv2) Protocol

Informational RFCs•• RFC 2367: PF_KEY Interface•• RFC 2412: The OAKLEY Key Determination Protocol•• RFC 3706: A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers•• RFC 3715: IPsec-Network Address Translation (NAT) Compatibility Requirements•• RFC 4621: Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol•• RFC 4809: Requirements for an IPsec Certificate Management Profile•• RFC 6071: IPsec and IKE Document Roadmap

Obsolete RFCs•• RFC 2401: Security Architecture for the Internet Protocol (IPsec overview) Obsolete by RFC 4301•• RFC 2409: The Internet Key Exchange•• RFC 4306: Internet Key Exchange (IKEv2) Protocol (obsoleted by RFC 5996)•• RFC 4718: IKEv2 Clarifications and Implementation Guidelines (obsoleted by RFC 5996)

References[1] The Internet Key Exchange (IKE), RFC 2409, §1 Abstract[2][2] RFC 2406, §1, page 2[3][3] RFC 3129[4] RFC 2367, PF_KEYv2 Key Management API, Dan McDonald, Bao Phan, & Craig Metz (July 1998)[5][5] RFC 6434, "IPv6 Node Requirements", E. Jankiewicz, J. Loughney, T. Narten (December 2011)[6] ipsecme charter (http:/ / www. ietf. org/ html. charters/ ipsecme-charter. html)[7] ipsecme status (http:/ / tools. ietf. org/ wg/ ipsecme/ )

External links• All IETF active security WGs (http:/ / www. ietf. org/ html. charters/ wg-dir. html#Security Area)

• IETF ipsecme WG (http:/ / datatracker. ietf. org/ wg/ ipsecme/ ) ("IP Security Maintenance and Extensions"Working Group)

• IETF btns WG (http:/ / www. ietf. org/ html. charters/ btns-charter. html) ("Better-Than-Nothing Security"Working Group) (chartered to work on unauthenticated IPsec, IPsec APIs, connection latching)]

• Securing Data in Transit with IPsec (http:/ / www. windowsecurity. com/ articles/Securing_Data_in_Transit_with_IPSec. html) WindowsSecurity.com article by Deb Shinder

• IPsec (http:/ / search. dmoz. org/ cgi-bin/ search?search=ipsec) at the Open Directory Project• IPsec (http:/ / www. microsoft. com/ ipsec) on Microsoft TechNet

• Microsoft IPsec Diagnostic Tool (http:/ / www. microsoft. com/ downloads/ details.aspx?FamilyID=1d4c292c-7998-42e4-8786-789c7b457881& displaylang=en) on Microsoft Download Center

• An Illustrated Guide to IPsec (http:/ / www. unixwiz. net/ techtips/ iguide-ipsec. html) by Steve Friedl

IPsec 18

• Security Architecture for IP (IPsec) (http:/ / www. ict. tuwien. ac. at/ lva/ 384. 081/ infobase/ L97-IPsec_v4-7.pdf) Data Communication Lectures by Manfred Lindner Part IPsec

• Creating VPNs with IPsec and SSL/TLS (http:/ / www. linuxjournal. com/ article/ 9916) Linux Journal article byRami Rosen

Layer 2 Tunneling ProtocolIn computer networking, Layer 2 Tunneling Protocol (L2TP) is a tunneling protocol used to support virtual privatenetworks (VPNs) or as part of the delivery of services by ISPs. It does not provide any encryption or confidentialityby itself. Rather, it relies on an encryption protocol that it passes within the tunnel to provide privacy.[1]

Internetprotocol suite

Application layer

•• DHCP•• DHCPv6•• DNS•• FTP•• HTTP•• IMAP•• IRC•• LDAP•• MGCP•• NNTP•• BGP•• NTP•• POP•• RPC•• RTP•• RTSP•• RIP•• SIP•• SMTP•• SNMP•• SOCKS•• SSH•• Telnet•• TLS/SSL•• XMPP•• more...

Transport layer

•• TCP•• UDP•• DCCP•• SCTP•• RSVP•• more...

Internet layer

Layer 2 Tunneling Protocol 19

•• IP•• IPv4•• IPv6

•• ICMP•• ICMPv6•• ECN•• IGMP•• IPsec•• more...

Link layer

•• ARP/InARP•• NDP•• OSPF•• Tunnels

•• L2TP•• PPP•• Media access control

•• Ethernet•• DSL•• ISDN•• FDDI

•• more...

HistoryPublished in 1999 as proposed standard RFC 2661, L2TP has its origins primarily in two older tunneling protocolsfor Point-to-Point communication: Cisco's Layer 2 Forwarding Protocol (L2F) and USRobotics Point-to-PointTunneling Protocol (PPTP). A new version of this protocol, L2TPv3, was published as proposed standard RFC 3931in 2005. L2TPv3 provides additional security features, improved encapsulation, and the ability to carry data linksother than simply PPP (PPP) over an IP network (e.g., Frame Relay, Ethernet, ATM, etc.).

DescriptionThe entire L2TP packet, including payload and L2TP header, is sent within a User Datagram Protocol (UDP)datagram. It is common to carry PPP sessions within an L2TP tunnel. L2TP does not provide confidentiality orstrong authentication by itself. IPsec is often used to secure L2TP packets by providing confidentiality,authentication and integrity. The combination of these two protocols is generally known as L2TP/IPsec (discussedbelow).The two endpoints of an L2TP tunnel are called the LAC (L2TP Access Concentrator) and the LNS (L2TP NetworkServer). The LAC is the initiator of the tunnel while the LNS is the server, which waits for new tunnels. Once atunnel is established, the network traffic between the peers is bidirectional. To be useful for networking, higher-levelprotocols are then run through the L2TP tunnel. To facilitate this, an L2TP session (or 'call') is established within thetunnel for each higher-level protocol such as PPP. Either the LAC or LNS may initiate sessions. The traffic for eachsession is isolated by L2TP, so it is possible to set up multiple virtual networks across a single tunnel. MTU shouldbe considered when implementing L2TP.The packets exchanged within an L2TP tunnel are categorized as either control packets or data packets. L2TPprovides reliability features for the control packets, but no reliability for data packets. Reliability, if desired, must beprovided by the nested protocols running within each session of the L2TP tunnel.

Layer 2 Tunneling Protocol 20

Tunneling modelsAn L2TP tunnel can extend across an entire PPP session or only across one segment of a two-segment session. Thiscan be represented by four different tunneling models, namely:•• voluntary tunnel• compulsory tunnel — incoming call• compulsory tunnel — remote dial• L2TP multihop connection[2]

L2TP packet structureAn L2TP packet consists of :

Bits 0–15 Bits 16–31

Flags and Version Info Length (opt)

Tunnel ID Session ID

Ns (opt) Nr (opt)

Offset Size (opt) Offset Pad (opt)......

Payload data

Field meanings:Flags and version

control flags indicating data/control packet and presence of length, sequence, and offset fields.Length (optional)

Total length of the message in bytes, present only when length flag is set.Tunnel ID

Indicates the identifier for the control connection.Session ID

Indicates the identifier for a session within a tunnel.Ns (optional)

sequence number for this data or control message, beginning at zero and incrementing by one (modulo 216) foreach message sent. Present only when sequence flag set.

Nr (optional)sequence number for expected message to be received. Nr is set to the Ns of the last in-order message receivedplus one (modulo 216). In data messages, Nr is reserved and, if present (as indicated by the S bit), MUST beignored upon receipt..

Offset Size (optional)Specifies where payload data is located past the L2TP header. If the offset field is present, the L2TP headerends after the last byte of the offset padding. This field exists if the offset flag is set.

Offset Pad (optional)Variable length, as specified by the offset size. Contents of this field are undefined.

Payload dataVariable length (Max payload size = Max size of UDP packet − size of L2TP header)

Layer 2 Tunneling Protocol 21

L2TP packet exchangeAt the time of setup of L2TP connection, many control packets are exchanged between server and client to establishtunnel and session for each direction. One peer requests the other peer to assign a specific tunnel and session idthrough these control packets. Then using this tunnel and session id, data packets are exchanged with the compressedPPP frames as payload.The list of L2TP Control messages exchanged between LAC and LNS, for handshaking before establishing a tunneland session in voluntary tunneling method are

L2TP/IPsecBecause of the lack of confidentiality inherent in the L2TP protocol, it is often implemented along with IPsec. This isreferred to as L2TP/IPsec, and is standardized in IETF RFC 3193. The process of setting up an L2TP/IPsec VPN isas follows:

1. Negotiation of IPsec security association (SA), typically through Internet key exchange (IKE). This is carriedout over UDP port 500, and commonly uses either a shared password (so-called "pre-shared keys"), publickeys, or X.509 certificates on both ends, although other keying methods exist.

2. Establishment of Encapsulating Security Payload (ESP) communication in transport mode. The IP protocolnumber for ESP is 50 (compare TCP's 6 and UDP's 17). At this point, a secure channel has been established,but no tunneling is taking place.

3.3. Negotiation and establishment of L2TP tunnel between the SA endpoints. The actual negotiation of parameterstakes place over the SA's secure channel, within the IPsec encryption. L2TP uses UDP port 1701.

When the process is complete, L2TP packets between the endpoints are encapsulated by IPsec. Since the L2TPpacket itself is wrapped and hidden within the IPsec packet, no information about the internal private network can begarnered from the encrypted packet. Also, it is not necessary to open UDP port 1701 on firewalls between theendpoints, since the inner packets are not acted upon until after IPsec data has been decrypted and stripped, which

Layer 2 Tunneling Protocol 22

only takes place at the endpoints.A potential point of confusion in L2TP/IPsec is the use of the terms tunnel and secure channel. The term tunnelrefers to a channel which allows untouched packets of one network to be transported over another network. In thecase of L2TP/PPP, it allows L2TP/PPP packets to be transported over IP. A secure channel refers to a connectionwithin which the confidentiality of all data is guaranteed. In L2TP/IPsec, first IPsec provides a secure channel, thenL2TP provides a tunnel.

Windows implementationWindows Vista provides two new configuration utilities that attempt to make using L2TP without IPsec easier, bothdescribed in sections that follow below:• an MMC snap-in called "Windows Firewall with Advanced Security" (WFwAS), located in Control Panel →

Administrative Tools• the "netsh advfirewall" command-line toolBoth these configuration utilities are not without their difficulties, and unfortunately, there is very littledocumentation about both "netsh advfirewall" and the IPsec client in WFwAS. One of the aforementioneddifficulties is that it is not compatible with NAT. Another problem is that servers must be specified only by IPaddress in the new Vista configuration utilities; the hostname of the server cannot be used, so if the IP address of theIPsec server changes, all clients will have to be informed of this new IP address (which also rules out servers thataddressed by utilities such as DynDNS).

L2TP in ISPs' networksL2TP is often used by ISPs when internet service over for example ADSL or cable is being resold. From the enduser, packets travel over a wholesale network service provider's network to a server called a Broadband RemoteAccess Server (BRAS), a protocol converter and router combined. On legacy networks the path from end usercustomer premises' equipment to the BRAS may be over an ATM network. From there on, over an IP network, anL2TP tunnel runs from the BRAS (acting as LAC) to an LNS which is an edge router at the boundary of the ultimatedestination ISP's IP network. See example of reseller ISPs using L2TP [3].

References[1][1] IETF (1999), RFC 2661, Layer Two Tunneling Protocol "L2TP"[2] http:/ / publib. boulder. ibm. com/ infocenter/ iseries/ v7r1m0/ index. jsp?topic=%2Frzaiy%2Frzaiymultihop. htm[3] http:/ / www. kitz. co. uk/ adsl/ equip2. htm

External links

Implementations• Cisco: Cisco L2TP documentation (http:/ / www. cisco. com/ en/ US/ docs/ ios/ 12_0t/ 12_0t1/ feature/ guide/

l2tpT. html), also read Technology brief from Cisco (http:/ / www. cisco. com/ warp/ public/ cc/ pd/ iosw/ tech/l2pro_tc. htm)

• Open source and Linux: xl2tpd (http:/ / www. xelerance. com/ software/ xl2tpd/ ), Linux RP-L2TP (http:/ /sourceforge. net/ projects/ rp-l2tp/ ), OpenL2TP (http:/ / sourceforge. net/ projects/ openl2tp/ ), l2tpns (http:/ /l2tpns. sourceforge. net/ ), l2tpd (http:/ / sourceforge. net/ projects/ l2tpd/ ) (inactive), Linux L2TP/IPsec server(http:/ / www. zeroshell. net/ eng/ vpndetails/ ), FreeBSD multi-link PPP daemon (http:/ / mpd. sourceforge. net/), OpenBSD npppd(8) (http:/ / www. openbsd. org/ cgi-bin/ cvsweb/ src/ usr. sbin/ npppd/ ), ACCEL-PPP -PPTP/L2TP/PPPoE server for Linux (http:/ / accel-ppp. sourceforge. net/ )

Layer 2 Tunneling Protocol 23

• Microsoft: built-in client included with Windows 2000 and higher; Microsoft L2TP/IPsec VPN Client (http:/ /www. microsoft. com/ technet/ prodtechnol/ windows2000serv/ support/ vpnclientag. mspx) for Windows98/Windows Me/Windows NT 4.0

•• Apple: built-in client included with Mac OS X 10.3 and higher.

Internet standards and extensions• RFC 2341 Cisco Layer Two Forwarding (Protocol) "L2F" (a predecessor to L2TP)• RFC 2637 Point-to-Point Tunneling Protocol (PPTP) (a predecessor to L2TP)• RFC 2661 Layer Two Tunneling Protocol "L2TP"• RFC 2809 Implementation of L2TP Compulsory Tunneling via RADIUS• RFC 2888 Secure Remote Access with L2TP• RFC 3070 Layer Two Tunneling Protocol (L2TP) over Frame Relay• RFC 3145 L2TP Disconnect Cause Information• RFC 3193 Securing L2TP using IPsec• RFC 3301 Layer Two Tunnelling Protocol (L2TP): ATM access network• RFC 3308 Layer Two Tunneling Protocol (L2TP) Differentiated Services• RFC 3355 Layer Two Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5 (AAL5)• RFC 3371 Layer Two Tunneling Protocol "L2TP" Management Information Base• RFC 3437 Layer Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation• RFC 3438 Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers: Internet Assigned Numbers

Authority (IANA) Considerations Update• RFC 3573 Signaling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP)• RFC 3817 Layer 2 Tunneling Protocol (L2TP) Active Discovery Relay for PPP over Ethernet (PPPoE)• RFC 3931 Layer Two Tunneling Protocol - Version 3 (L2TPv3)• RFC 4045 Extensions to Support Efficient Carrying of Multicast Traffic in Layer-2 Tunneling Protocol (L2TP)• RFC 4951 Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) "failover"

Other• IANA assigned numbers for L2TP (http:/ / www. iana. org/ assignments/ l2tp-parameters)• L2TP Extensions Working Group (l2tpext) (http:/ / www. ietf. org/ html. charters/ l2tpext-charter. html) - (where

future standardization work is being coordinated)• Using Linux as an L2TP/IPsec VPN client (http:/ / www. jacco2. dds. nl/ networking/ linux-l2tp. html)• L2TP/IPSec with OpenBSD and npppd (http:/ / undeadly. org/ cgi?action=article& sid=20120427125048&

mode=expanded& count=3)

L2TPv3 24

L2TPv3

Internetprotocol suite

Application layer

•• DHCP•• DHCPv6•• DNS•• FTP•• HTTP•• IMAP•• IRC•• LDAP•• MGCP•• NNTP•• BGP•• NTP•• POP•• RPC•• RTP•• RTSP•• RIP•• SIP•• SMTP•• SNMP•• SOCKS•• SSH•• Telnet•• TLS/SSL•• XMPP•• more...

Transport layer

•• TCP•• UDP•• DCCP•• SCTP•• RSVP•• more...

Internet layer

•• IP•• IPv4•• IPv6

•• ICMP•• ICMPv6•• ECN•• IGMP•• IPsec•• more...

L2TPv3 25

Link layer

•• ARP/InARP•• NDP•• OSPF•• Tunnels

•• L2TP•• PPP•• Media access control

•• Ethernet•• DSL•• ISDN•• FDDI

•• more...

Layer 2 Tunneling Protocol Version 3 is an IETF standard related to L2TP that can be used as an alternativeprotocol to Multiprotocol Label Switching (MPLS) for encapsulation of multiprotocol Layer 2 communicationstraffic over IP networks. Like L2TP, L2TPv3 provides a pseudo-wire service, but scaled to fit carrier requirements.L2TPv3 can be regarded as being to MPLS what IP is to ATM: a simplified version of the same concept, with muchof the goodness achieved with a fraction of the effort, at the cost of losing some technical features considered lessimportant in the market. In the case of L2TPv3, the features lost are teletraffic engineering features consideredimportant in MPLS. However, there is no reason why these features could not be re-engineered in or on top ofL2TPv3 in later products. The protocol overhead of L2TPv3 is also significantly bigger than MPLS.

Implementations• Cisco [1]

•• Brocade• Linux [2]

• ProL2TP [3]

External links• IETF L2TPEXT working group [4]

• RFC 3931 - Layer Two Tunneling Protocol - Version 3 (L2TPv3) [5]

• RFC 2661 - Layer Two Tunneling Protocol "L2TP" [6]

References[1] http:/ / www. cisco. com/ en/ US/ docs/ ios/ 12_0s/ feature/ guide/ l2tpv30s. html[2] http:/ / www. kernel. org/ doc/ Documentation/ networking/ l2tp. txt[3] http:/ / www. prol2tp. com[4] http:/ / www. ietf. org/ html. charters/ l2tpext-charter. html[5] http:/ / tools. ietf. org/ html/ rfc3931[6] http:/ / tools. ietf. org/ html/ rfc2661

Point-to-Point Tunneling Protocol 26

Point-to-Point Tunneling ProtocolThe Point-to-Point Tunneling Protocol (PPTP) is a method for implementing virtual private networks. PPTP usesa control channel over TCP and a GRE tunnel operating to encapsulate PPP packets.The PPTP specification does not describe encryption or authentication features and relies on the Point-to-PointProtocol being tunneled to implement security functionality. However, the most common PPTP implementationshipping with the Microsoft Windows product families implements various levels of authentication and encryptionnatively as standard features of the Windows PPTP stack. The intended use of this protocol is to provide securitylevels and remote access levels comparable with typical VPN products.

Internetprotocol suite

Application layer

•• DHCP•• DHCPv6•• DNS•• FTP•• HTTP•• IMAP•• IRC•• LDAP•• MGCP•• NNTP•• BGP•• NTP•• POP•• RPC•• RTP•• RTSP•• RIP•• SIP•• SMTP•• SNMP•• SOCKS•• SSH•• Telnet•• TLS/SSL•• XMPP•• more...

Transport layer

•• TCP•• UDP•• DCCP•• SCTP•• RSVP•• more...

Internet layer

Point-to-Point Tunneling Protocol 27

•• IP•• IPv4•• IPv6

•• ICMP•• ICMPv6•• ECN•• IGMP•• IPsec•• more...

Link layer

•• ARP/InARP•• NDP•• OSPF•• Tunnels

•• L2TP•• PPP•• Media access control

•• Ethernet•• DSL•• ISDN•• FDDI

•• more...

SpecificationA specification for PPTP was published in July 1999 as RFC 2637[1] and was developed by a vendor consortiumformed by Microsoft, Ascend Communications (today part of Alcatel-Lucent), 3Com, and others. PPTP has not beenproposed nor ratified as a standard by the IETF.A PPTP tunnel is instantiated by communication to the peer on TCP port 1723. This TCP connection is then used toinitiate and manage a second GRE tunnel to the same peer.The PPTP GRE packet format is non standard, including an additional acknowledgement field replacing the typicalrouting field in the GRE header. However, as in a normal GRE connection, those modified GRE packets are directlyencapsulated into IP packets, and seen as IP protocol number 47.The GRE tunnel is used to carry encapsulated PPP packets, allowing the tunnelling of any protocols that can becarried within PPP, including IP, NetBEUI and IPX.In the Microsoft implementation, the tunneled PPP traffic can be authenticated with PAP, CHAP, MS-CHAP v1/v2or EAP-TLS. The PPP payload is encrypted using Microsoft Point-to-Point Encryption (MPPE) when usingMS-CHAPv1/v2 or EAP-TLS. MPPE is described by RFC 3078.

ImplementationsPPTP was the first VPN protocol that was supported by Microsoft Dial-up Networking. All releases of MicrosoftWindows since Windows 95 OSR2 are bundled with a PPTP client, although they are limited to only 2 concurrentoutbound connections. Microsoft Windows Mobile 2003 and higher also support the PPTP protocol. The Routingand Remote Access Service for Microsoft Windows contains a PPTP server. The Microsoft implementation usessingle DES in the MS-CHAP authentication protocol which many find unsuitable for data protection needs.Windows Vista and later support the use of PEAP with PPTP. The authentication mechanisms supported are PEAPv0/EAP-MSCHAPv2 (passwords) and PEAP-TLS (smartcards and certificates). Windows Vista removed

Point-to-Point Tunneling Protocol 28

support for using the MSCHAP-v1 protocol to authenticate remote access connections.Linux server-side support for PPTP is provided by the PoPToP daemon and kernel modules for PPP and MPPE. Thefirst PPTP implementation was developed by Matthew Ramsay in 1999 and initially distributed under the GNU GPLby Moreton Bay. However, Linux distributions initially lacked full PPTP support because MPPE was believed to bepatent encumbered. Full MPPE support was added to the Linux kernel in the 2.6.14 release on October 28, 2005.SuSE Linux 10 was the first Linux distribution to provide a complete working PPTP client. There is alsoACCEL-PPP – PPTP/L2TP/PPPoE server for Linux which supports PPTP in kernel-mode.OS X and iOS are bundled with a PPTP client. Cisco and Efficient Networks sell PPTP clients for older Mac OSreleases. Palm PDA devices with Wi-Fi are bundled with the Mergic PPTP client.[citation needed]

Many different Mobile phones with Android as the operating system support PPTP as well.

SecurityPPTP has been the subject of many security analyses and serious security vulnerabilities have been found in theprotocol. The known vulnerabilities relate to the underlying PPP authentication protocols used, the design of theMPPE protocol as well as the integration between MPPE and PPP authentication for session key establishment.PPTP is (as of Oct 2012) considered cryptographically broken and its use is no longer recommended by Microsoft.A summary of these vulnerabilities is below:• MSCHAP-v1 is fundamentally insecure. Tools exist to trivially extract the NT Password hashes from a captured

MSCHAP-v1 exchange.[2]

• When using MSCHAP-v1, MPPE uses the same RC4 session key for encryption in both directions of thecommunication flow. This can be cryptanalysed with standard methods by XORing the streams from eachdirection together.[3]

• MSCHAP-v2 is vulnerable to dictionary attack on the captured challenge response packets. Tools exist to performthis process rapidly.[4]

•• In 2012 it was shown that brute-force attack on MSCHAP-v2 is equivalent to single DES key brute-force attack.Online service was presented, which is capable to restore MSCHAP-v2 passphrase's MD4 in 23 hours.

•• MPPE uses RC4 stream cipher for encryption. There is no method for authentication of the ciphertext stream andtherefore the ciphertext is vulnerable to a bit-flipping attack. An attacker could modify the stream in transit andadjust single bits to change the output stream without possibility of detection. These bit flips may be detected bythe protocols themselves through checksums or other means.

EAP-TLS is seen as the superior authentication choice for PPTP;[5] however, it requires implementation of a PublicKey Infrastructure for both client and server certificates. As such it is not a viable authentication option for manyremote access installations.

References[1][1] RFC 2637[2] Bruce Schneier, Cryptanalysis of Microsoft's Point to Point Tunneling Protocol (PPTP) (http:/ / www. schneier. com/ paper-pptp. pdf).[3] Bruce Schneier, Cryptanalysis of Microsoft's PPTP Authentication Extensions (MS-CHAPv2), October 19 1999 (http:/ / www. schneier. com/

paper-pptpv2. pdf).[4] Josh of willhackforsushi.com " news (http:/ / www. willhackforsushi. com/ Asleap. html)".[5] Choosing EAP-TLS or MS-CHAP v2 for User-Level Authentication (http:/ / technet. microsoft. com/ en-us/ library/ cc739638(WS. 10).

aspx), Microsoft TechNet, March 28, 2003

Point-to-Point Tunneling Protocol 29

External links• Windows NT: Understanding PPTP (http:/ / www. microsoft. com/ technet/ archive/ winntas/ plan/ pptpudst.

mspx) from Microsoft• FAQ on security flaws in Microsoft's implementation (http:/ / www. schneier. com/ pptp-faq. html), Bruce

Schneier, 1998• Cryptanalysis of Microsoft's PPTP Authentication Extensions (http:/ / www. schneier. com/ paper-pptpv2. html)

(MS-CHAPv2), Bruce Schneier, 1999PPTP VPN Configuration (http:/ / www. thefreevpn. net/ setup-vpn/ )

Split tunnelingSplit tunneling is a computer networking concept which allows a VPN user to access a public network (e.g., theInternet) and a local LAN or WAN at the same time, using the same physical network connection. This connectionservice is usually facilitated through a program such as a VPN client software application.For example, suppose a user utilizes a remote access VPN software client connecting to a corporate network using ahotel wireless network. The user with split tunneling enabled is able to connect to file servers, database servers, mailservers and other servers on the corporate network through the VPN connection. When the user connects to Internetresources (Web sites, FTP sites, etc.), the connection request goes directly out the gateway provided by the hotelnetwork.

AdvantagesOne advantage of using split tunneling is that it alleviates bottlenecks and conserves bandwidth as Internet trafficdoes not have to pass through the VPN server.Another advantage is in the case where a user works at a supplier or partner site and needs access to networkresources on both networks throughout the day. Split tunneling prevents the user from having to continually connectand disconnect.

DisadvantagesA disadvantage is that when split tunneling is enabled, users bypass gateway level security that might be in placewithin the company infrastructure. For example, if web or content filtering is in place, this is something usuallycontrolled at a gateway level, not the client PC.ISPs that implement DNS hijacking break name resolution of private addresses with a splittunnel.Wikipedia:Disputed statement

Split tunneling 30

Trust issuesThere are many variants of split tunneling that attempt to address this fundamental trust issue. Often when plain splittunneling is enabled, datagrams by default will go out the local network interface's default gateway. Only datagramsthat are destined for IP networks behind the VPN terminator will go through the tunnel. This violates the principle ofleast privilege if a user does not absolutely require access to the entire Internet.

Variants and related technology

Inverse split tunnelingA variant of this split tunneling is called "inverse" split tunneling. By default all datagrams enter the tunnel exceptthose destination IPs explicitly allowed by VPN gateway. The criteria for allowing datagrams to exit the localnetwork interface (outside the tunnel) may vary from vendor to vendor (i.e.: port, service, etc.) This keeps control ofnetwork gateways to a centralized policy device such as the VPN terminator. This can be augmented by endpointpolicy enforcement technologies such as an interface firewall on the endpoint device's network interface driver,group policy object or anti-malware agent. This is related in many ways to network access control (NAC).

IPv6 dual-stack networkingInternal IPv6 content can be hosted and presented to sites via a unique local address range at the VPN level, whileexternal IPv4 & IPv6 content can be accessed via site routers.

References• http:/ / www. isaserver. org/ tutorials/ 2004fixipsectunnel. html

Transport Layer Security 31

Transport Layer SecurityTransport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocolsthat are designed to provide communication security over the Internet. They use X.509 certificates and henceasymmetric cryptography to assure the counterparty whom they are talking with, and to exchange a symmetric key.This session key is then used to encrypt data flowing between the parties. This allows for data/messageconfidentiality, and message authentication codes for message integrity and as a by-product message authentication.Several versions of the protocols are in widespread use in applications such as web browsing, electronic mail,Internet faxing, instant messaging and voice-over-IP (VoIP). An important property in this context is perfect forwardsecrecy, so the short term session key cannot be derived from the long term asymmetric secret key.[1]

As a consequence of choosing X.509 certificates, certificate authorities and a public key infrastructure are necessaryto verify the relation between a certificate and its owner, as well as to generate, sign, and administer the validity ofcertificates. While this can be more beneficial than verifying the identities via a web of trust, the 2013 masssurveillance disclosures made it more widely known that certificate authorities are a weak point from a securitystandpoint, allowing man-in-the-middle attacks.[2][3]

In the TCP/IP model view, TLS and SSL encrypt the data of network connections at a lower sublayer of itsapplication layer. In OSI model equivalences, TLS/SSL is initialized at layer 5 (the session layer) then works at layer6 (the presentation layer): first the session layer has a handshake using an asymmetric cipher in order to establishcipher settings and a shared key for that session; then the presentation layer encrypts the rest of the communicationusing a symmetric cipher and that session key. In both models, TLS and SSL work on behalf of the underlyingtransport layer, whose segments carry encrypted data.TLS is an IETF standards track protocol, first defined in 1999 and last updated in RFC 5246 (August 2008) and RFC6176 (March 2011). It is based on the earlier SSL specifications (1994, 1995, 1996) developed by NetscapeCommunications for adding the HTTPS protocol to their Navigator web browser.

Internetprotocol suite

Application layer

•• DHCP•• DHCPv6•• DNS•• FTP•• HTTP•• IMAP•• IRC•• LDAP•• MGCP•• NNTP•• BGP•• NTP•• POP•• RPC•• RTP•• RTSP•• RIP•• SIP•• SMTP

Transport Layer Security 32

•• SNMP•• SOCKS•• SSH•• Telnet•• TLS/SSL•• XMPP•• more...

Transport layer

•• TCP•• UDP•• DCCP•• SCTP•• RSVP•• more...

Internet layer

•• IP•• IPv4•• IPv6

•• ICMP•• ICMPv6•• ECN•• IGMP•• IPsec•• more...

Link layer

•• ARP/InARP•• NDP•• OSPF•• Tunnels

•• L2TP•• PPP•• Media access control

•• Ethernet•• DSL•• ISDN•• FDDI

•• more...

DescriptionThe TLS protocol allows client-server applications to communicate across a network in a way designed to preventeavesdropping and tampering.Since protocols can operate either with or without TLS (or SSL), it is necessary for the client to indicate to the serverwhether it wants to set up a TLS connection or not. There are two main ways of achieving this; one option is to use adifferent port number for TLS connections (for example port 443 for HTTPS). The other is to use the regular portnumber and have the client request that the server switch the connection to TLS using a protocol-specific mechanism(for example STARTTLS for mail and news protocols).Once the client and server have decided to use TLS, they negotiate a stateful connection by using a handshaking procedure.[4] During this handshake, the client and server agree on various parameters used to establish the

Transport Layer Security 33

connection's security:1.1. The client sends the server the client's SSL version number, cipher settings, session-specific data, and other

information that the server needs to communicate with the client using SSL.2.2. The server sends the client the server's SSL version number, cipher settings, session-specific data, and other

information that the client needs to communicate with the server over SSL. The server also sends its owncertificate, and if the client is requesting a server resource that requires client authentication, the server requeststhe client's certificate.

3.3. The client uses the information sent by the server to authenticate the server. If the server cannot be authenticated,the user is warned of the problem and informed that an encrypted and authenticated connection cannot beestablished. If the server can be successfully authenticated, the client proceeds to the next step.

4. Using all data generated in the handshake thus far, the client (with the cooperation of the server, depending on thecipher in use) creates the pre-master secret for the session, encrypts it with the server's public key (obtained fromthe server's certificate, sent in step 2), and then sends the encrypted pre-master secret to the server.

5.5. If the server has requested client authentication (an optional step in the handshake), the client also signs anotherpiece of data that is unique to this handshake and known by both the client and server. In this case, the clientsends both the signed data and the client's own certificate to the server along with the encrypted pre-master secret.

6.6. If the server has requested client authentication, the server attempts to authenticate the client. If the client cannotbe authenticated, the session ends. If the client can be successfully authenticated, the server uses its private key todecrypt the pre-master secret, and then performs a series of steps (which the client also performs, starting from thesame pre-master secret) to generate the master secret.

7.7. Both the client and the server use the master secret to generate the session keys, which are symmetric keys usedto encrypt and decrypt information exchanged during the SSL session and to verify its integrity (that is, to detectany changes in the data between the time it was sent and the time it is received over the SSL connection).

8.8. The client sends a message to the server informing it that future messages from the client will be encrypted withthe session key. It then sends a separate (encrypted) message indicating that the client portion of the handshake isfinished.

9.9. The server sends a message to the client informing it that future messages from the server will be encrypted withthe session key. It then sends a separate (encrypted) message indicating that the server portion of the handshake isfinished.

The SSL handshake is now complete and the session begins. The client and the server use the session keys to encryptand decrypt the data they send to each other and to validate its integrity.This is the normal operation condition of the secure channel. At any time, due to internal or external stimulus (eitherautomation or user intervention), either side may renegotiate the connection, in which case, the process repeats itself.This concludes the handshake and begins the secured connection, which is encrypted and decrypted with the keymaterial until the connection closes.If any one of the above steps fails, the TLS handshake fails and the connection is not created.In step 3, the client must check a chain of "signatures" from a "root of trust" built into, or added to, the client. Theclient must also check that none of these have been revoked; this is not often implemented correctly, but is arequirement of any public-key authentication system. If the particular signer beginning this server's chain is trusted,and all signatures in the chain remain trusted, then the Certificate (thus the server) is trusted.

Transport Layer Security 34

History and development

Secure Network Programming APIEarly research efforts toward transport layer security included the Secure Network Programming (SNP)application programming interface (API), which in 1993 explored the approach of having a secure transport layerAPI closely resembling Berkeley sockets, to facilitate retrofitting preexisting network applications with securitymeasures.[5]

SSL 1.0, 2.0 and 3.0The SSL protocol was originally developed by Netscape. Version 1.0 was never publicly released; version 2.0 wasreleased in February 1995 but "contained a number of security flaws which ultimately led to the design of SSLversion 3.0."[6] SSL version 3.0, released in 1996, was a complete redesign of the protocol produced by Paul Kocherworking with Netscape engineers Phil Karlton and Alan Freier. Newer versions of SSL/TLS are based on SSL 3.0.The 1996 draft of SSL 3.0 was published by IETF as a historical document in RFC 6101.

TLS 1.0TLS 1.0 was first defined in RFC 2246 in January 1999 as an upgrade of SSL Version 3.0. As stated in the RFC, "thedifferences between this protocol and SSL 3.0 are not dramatic, but they are significant to preclude interoperabilitybetween TLS 1.0 and SSL 3.0. " TLS 1.0 does include a means by which a TLS implementation can downgrade theconnection to SSL 3.0, thus weakening security.

TLS 1.1TLS 1.1 was defined in RFC 4346 in April 2006. It is an update from TLS version 1.0. Significant differences in thisversion include:• Added protection against Cipher block chaining (CBC) attacks.

• The implicit Initialization Vector (IV) was replaced with an explicit IV.• Change in handling of padding errors.

• Support for IANA registration of parameters.

TLS 1.2TLS 1.2 was defined in RFC 5246 in August 2008. It is based on the earlier TLS 1.1 specification. Major differencesinclude:• The MD5-SHA-1 combination in the pseudorandom function (PRF) was replaced with SHA-256, with an option

to use cipher suite specified PRFs.•• The MD5-SHA-1 combination in the Finished message hash was replaced with SHA-256, with an option to use

cipher suite specific hash algorithms. However the size of the hash in the finished message is still truncated to96-bits.

• The MD5-SHA-1 combination in the digitally signed element was replaced with a single hash negotiated duringhandshake, defaults to SHA-1.

•• Enhancement in the client's and server's ability to specify which hash and signature algorithms they will accept.• Expansion of support for authenticated encryption ciphers, used mainly for Galois/Counter Mode (GCM) and

CCM mode of Advanced Encryption Standard encryption.• TLS Extensions definition and Advanced Encryption Standard cipher suites were added.All TLS versions were further refined in RFC 6176 in March 2011 removing their backward compatibility with SSLsuch that TLS sessions will never negotiate the use of Secure Sockets Layer (SSL) version 2.0.

Transport Layer Security 35

Applications and adoptionIn applications design, TLS is usually implemented on top of any of the Transport Layer protocols, encapsulating theapplication-specific protocols such as HTTP, FTP, SMTP, NNTP and XMPP. Historically it has been used primarilywith reliable transport protocols such as the Transmission Control Protocol (TCP). However, it has also beenimplemented with datagram-oriented transport protocols, such as the User Datagram Protocol (UDP) and theDatagram Congestion Control Protocol (DCCP), usage which has been standardized independently using the termDatagram Transport Layer Security (DTLS).

WebsitesA prominent use of TLS is for securing World Wide Web traffic between the website and the browser carried byHTTP to form HTTPS. Notable applications are electronic commerce and asset management.

Website protocol support

Protocolversion

Websitesupport

[7]Security

SSL 2.0 26.2% (-0.7%) Insecure

SSL 3.0 99.7% (±0%) Depends on cipher and client BEAST mitigation[8][9][10][]

TLS 1.0 99.3% (±0%) Depends on cipher and client BEAST mitigation[11]

TLS 1.1 17.2% (+1.8%) Depends on cipher

TLS 1.2 19.7% (+1.9%) Depends on cipher

Notes[1] SSL: Intercepted today, decrypted tomorrow (http:/ / news. netcraft. com/ archives/ 2013/ 06/ 25/ ssl-intercepted-today-decrypted-tomorrow.

html), Netcraft, 2013-06-25.[2] Law Enforcement Appliance Subverts SSL (http:/ / www. wired. com/ threatlevel/ 2010/ 03/ packet-forensics/ ), Wired, 2010-04-03.[3] New Research Suggests That Governments May Fake SSL Certificates (https:/ / www. eff. org/ deeplinks/ 2010/ 03/

researchers-reveal-likelihood-governments-fake-ssl), EFF, 2010-03-24.[4] " SSL/TLS in Detail (http:/ / technet. microsoft. com/ en-us/ library/ cc785811. aspx)". Microsoft TechNet. Updated July 31, 2003.[5] Thomas Y. C. Woo, Raghuram Bindignavle, Shaowen Su and Simon S. Lam, SNP: An interface for secure network programming

Proceedings USENIX Summer Technical Conference, June 1994[6][6] Rescorla 2001[7][7] As of October 02, 2013.[8][8] see Website cipher security table below[9][9] various RC4 attacks weaken or break RC4 used in SSL/TLS[10] the CRIME attack means that TLS compression is not secure, and the BREACH attack that requires HTTP compression can be used to

defeat the security of both TLS and SSL 3.0 that is patched with RFC 5746 when HTTP compression is enabled[11][11] RFC 5746 must be implemented in order to fix a renegotiation flaw that would otherwise break this protocol.

Key exchange or key agreementBefore a client and server can begin to exchange information protected by TLS, they must securely exchange oragree upon an encryption key and a cipher to use when encrypting data (see Cipher). Among the methods used forkey exchange/agreement are: public and private keys generated with RSA (denoted TLS_RSA in the TLS handshakeprotocol), Diffie-Hellman (denoted TLS_DH in the TLS handshake protocol), ephemeral Diffie-Hellman (denotedTLS_DHE in the handshake protocol), ECDH (denoted TLS_ECDH), ephemeral Elliptic Curve Diffie-Hellman(TLS_ECDHE), anonymous Diffie-Hellman (TLS_DH_anon), and PSK (TLS_PSK).The TLS_DH_anon key agreement method does not authenticate the server or the user and hence is rarely used.Only TLS_DHE and TLS_ECDHE provide perfect forward secrecy.

Transport Layer Security 36

Public key certificates used during exchange/agreement also vary in the size of the public/private encryption keysused during the exchange and hence the robustness of the security provided. In July 2013, Google announced that itwould no longer use 1024 bit public keys and would switch instead to 2048 bit keys to increase the security of theTLS encryption it provides to its users.

Cipher

Website cipher security against publicly known feasible attacks

Protocolversion

Security[7]

3DES CBC AES CBC AES CCM AES GCM Camellia CBC Camellia GCM DES CBC IDEA CBC RC2 CBC RC4

SSL 2.0 Insecure N/A N/A N/A N/A N/A Insecure Insecure Insecure Insecure

SSL 3.0[]

Depends[1][10][2] N/A N/A N/A N/A N/A Insecure Depends Insecure Insecure

[9]

TLS 1.0Depends Depends N/A N/A N/A N/A Insecure Depends Insecure Insecure

[11]

TLS 1.1 Secure Secure N/A N/A N/A N/A Insecure Secure Insecure Insecure

TLS 1.2 Secure Secure Secure Secure[3]

Secure SecureN/A N/A N/A Insecure

Notes[1][1] the BEAST attack breaks all block ciphers used in SSL 3.0 and TLS 1.0 unless mitigated by the client. , Apple has not turned on this

mitigation by default resulting in Safari still being theoretically vulnerable to the BEAST attack on those platforms - see #Web browsers[2] This can be attacked with the Lucky 13 attack if the library is not written carefully to eliminate timing side channels.[3] The AES GCM cipher suites which were defined for TLS 1.2 are secure

Web browsersAs of October 2013 (http:/ / en. wikipedia. org/ w/ index. php?title=Transport_Layer_Security& action=edit), allmajor web browsers support TLS:

Browser support for TLS

Browser Version Platforms TLS 1.0 TLS 1.1 TLS 1.2 VulnerabilitiesFixed

[1]

Chrome[2]

</ref>[3]

</ref>

0-21 Android,iOS,

Linux,Mac OS X,

Windows (XP,Vista, 7, 8)

Yes No No -

22–29 Yes Yes No -

30-current Yes Yes Yes Depends

Firefox[4]

</ref>

1–18 Android,Linux,

Mac OS X,Windows (XP,

Vista, 7, 8)

Yes No No -

19-23Yes

Yes,disabled by

defaultNo

-

24-currentYes

Yes,disabled by

default

Yes,disabled

by defaultDepends

Transport Layer Security 37

InternetExplorer[5]

</ref>

6 Windows (98, 2000,ME, XP)

Yes,disabled

by defaultNo No

-

7–8 Windows XP Yes No No Depends

7–9 Windows Vista Yes No No Depends

8–10 Windows 7Yes

Yes,disabled by

default

Yes,disabled

by defaultDepends

10 Windows 8Yes

Yes,disabled by

default

Yes,disabled

by defaultDepends

11preview

Windows (7,8)[citation needed] Yes Yes [citation

needed]Yes [citation

needed] Depends

11preview

Windows 8.1 Yes Yes [citation

needed]Yes [citation

needed] Depends[6]

Opera[7]

TLS 1.1 and 1.2 are disabled by default (exceptfor version 9

[8] that enabled TLS 1.1 by

default).</ref>[9]

5-7 Android,[citation

needed]

iOS,[citation needed]

Linux,Mac OS X,Windows

Yes [10] No No -

8–9

Yes

Yes,disabled by

default[11]

No

-

10–12Yes

Yes,disabled by

default

Yes,disabled

by default

-

14–16 Yes Yes [12] No -

17-current Yes Yes [13] Yes Depends

Safari[14]

with unknown version, Safari 5 is the lastversion available for Windows. OS X 10.8 on haveSecureTransport support for TLS 1.1 and 1.2

[15]

Qualys SSL report simulates Safari 5.1.9 connectingwith TLS 1.0 not 1.1 or 1.2

[16]</ref>

4 iOS 4.0,[17]</ref>Mac OS X,

Windows (XP,Vista, 7)

Yes No No

-

5 Windows (XP,Vista, 7, 8)

Yes No No-

5-current Mac OS X Yes No No No

5–current iOS 5.0[][18]</ref> Yes Yes Yes No

7 preview Mac OS X 10.9preview[19]</ref>

Yes Yes Yes?

Notes[1][1] Does the current browser have mitigations or is not vulnerable for all the known protocol and cipher attacks listed in this page (BEAST,

CRIME, BREACH, Lucky Thirteen). Note actual security depends on other factors such as negotiated cipher (such as RC4), encryptionstrength etc. Non-current browsers will have unfixed security issues so are not considered.

[2] Google Chrome (and Chromium) supports TLS 1.0, and TLS 1.1 from version 22 (it was added, then dropped from version 21). TLS 1.2support has been added, then dropped from Chrome 29.<ref>

[3] Uses the TLS implementation provided by NSS. NSS 3.14.3 supports TLS 1.0 and 1.1 but not 1.2. As of 2 July 2013 (http:/ / en. wikipedia.org/ w/ index. php?title=Transport_Layer_Security& action=edit), TLS 1.2 has been implemented in NSS 3.15.1.<ref>

[4] As of Firefox 19, Firefox supports only TLS 1.0 despite the bundled NSS supporting TLS 1.1 SSL: Intercepted today, decrypted tomorrow (http:/ / news. netcraft. com/ archives/ 2013/ 06/ 25/ ssl-intercepted-today-decrypted-tomorrow. html), Netcraft, 2013-06-25. Since Firefox 19, TLS 1.1 has been implemented and can be enabled, but was not enabled by default due to issues, and was subsequently backed out. Firefox 24

Transport Layer Security 38

has TLS 1.2 support. Neither TLS 1.1 or 1.2 is enabled by default in these versions. <ref> MozillaZine article (http:/ / kb. mozillazine. org/Security. tls. version. *)

[5] IE uses the TLS implementation of the Microsoft Windows operating system provided by the SChannel security support provider. TLS 1.1and 1.2 are disabled by default.<ref>

[6] http:/ / technet. microsoft. com/ en-us/ library/ dn303404. aspx[7] Opera 10 added support for TLS 1.2 as of Presto 2.2. Previous support was for TLS 1.0 and 1.1.<ref>[8] "Changelog for Opera 9.0 for Windows" (http:/ / www. opera. com/ docs/ changelogs/ windows/ 900/ ) at Opera.com[9][9] TLS support of Opera 14 and above is same as that of Chrome, because Opera has migrated to Chromium backend.[10] "Changelog for Opera 5.x for Windows" (http:/ / www. opera. com/ docs/ changelogs/ windows/ 500-512/ ) at Opera.com[11] "Changelog for Opera UNIQ-nowiki-2-5532d68d52617aad-QINU Beta 2 for Windows" (http:/ / www. opera. com/ docs/ changelogs/

windows/ 800b2/ ) at Opera.com[12][12] same as Chrome 27-29[13][13] same as Chrome 30-current[14] Safari uses the operating system implementation on Mac OS X, Windows (XP, Vista, 7)<ref>[15] Curl: Patch to add TLS 1.1 and 1.2 support & replace deprecated functions in SecureTransport (http:/ / curl. haxx. se/ mail/ lib-2012-08/

0120. html)[16] Qualys SSL Report: google.co.uk (https:/ / www. ssllabs. com/ ssltest/ analyze. html?d=google. co. uk& s=74. 125. 227. 183) (simulation

Safari 5.1.9 TLS 1.0)[17] As of September 2013 (http:/ / en. wikipedia. org/ w/ index. php?title=Transport_Layer_Security& action=edit), Apple has implemented

BEAST mitigation in OS X 10.8 (Mountain Lion) and possibly iOS, but it is not turned on by default resulting in Safari still beingtheoretically vulnerable to the BEAST attack on those platforms<ref name="BEAST-Still">

[18][18] , section "HTTPS (SSL/TLS)"[19] Simulated connection by Qualys. <ref>

LibrariesSeveral free and open source software projects have implemented SSL and TLS. Programmers may use thePolarSSL, CyaSSL, OpenSSL, MatrixSSL, NSS, or GnuTLS libraries for SSL/TLS functionality.• Microsoft Windows includes an implementation of SSL and TLS as part of its Secure Channel package.• OS X includes an implementation of SSL and TLS as part of its Secure Transport package.• Delphi programmers may use a library called Indy.• OpenSSL: a free implementation (BSD license with some extensions)• GnuTLS: a free implementation (LGPL licensed)• cryptlib: a portable open source cryptography library (includes TLS/SSL implementation)• JSSE: a Java implementation included in the Java Runtime Environment supports TLS 1.1 and 1.2 from Java 7,

although is disabled by default for client, and enabled by default for server• MatrixSSL: a dual licensed implementation• Network Security Services (NSS): FIPS 140 validated open source library• PolarSSL: A tiny SSL library implementation for embedded devices that is designed for ease of use• CyaSSL: Embedded SSL/TLS Library with a strong focus on speed and size.A paper presented at the 2012 ACM conference on computer and communications security showed that fewapplications used some of these SSL libraries incorrectly, leading to vulnerabilities. According to the authors

"the root cause of most of these vulnerabilities is the terrible design of the APIs to the underlying SSLlibraries. Instead of expressing high-level security properties of network tunnels such as confidentialityand authentication, these APIs expose low-level details of the SSL protocol to application developers.As a consequence, developers often use SSL APIs incorrectly, misinterpreting and misunderstandingtheir manifold parameters, options, side effects, and return values."

Transport Layer Security 39

Other usesThe Simple Mail Transfer Protocol (SMTP) can also be protected by TLS. These applications use public keycertificates to verify the identity of endpoints.TLS can also be used to tunnel an entire network stack to create a VPN, as is the case with OpenVPN andOpenConnect. Many vendors now marry TLS's encryption and authentication capabilities with authorization. Therehas also been substantial development since the late 1990s in creating client technology outside of the browser toenable support for client/server applications. When compared against traditional IPsec VPN technologies, TLS hassome inherent advantages in firewall and NAT traversal that make it easier to administer for large remote-accesspopulations.TLS is also a standard method to protect Session Initiation Protocol (SIP) application signaling. TLS can be used toprovide authentication and encryption of the SIP signaling associated with VoIP and other SIP-based applications.

Security

SSL 2.0SSL 2.0 is flawed in a variety of ways:•• Identical cryptographic keys are used for message authentication and encryption.• SSL 2.0 has a weak MAC construction that uses the MD5 hash function with a secret prefix, making it vulnerable

to length extension attacks.• SSL 2.0 does not have any protection for the handshake, meaning a man-in-the-middle downgrade attack can go

undetected.•• SSL 2.0 uses the TCP connection close to indicate the end of data. This means that truncation attacks are possible:

the attacker simply forges a TCP FIN, leaving the recipient unaware of an illegitimate end of data message (SSL3.0 fixes this problem by having an explicit closure alert).

•• SSL 2.0 assumes a single service and a fixed domain certificate, which clashes with the standard feature of virtualhosting in Web servers. This means that most websites are practically impaired from using SSL.

SSL 2.0 is disabled by default, beginning with Internet Explorer 7, Mozilla Firefox 2, Opera 9.5,[1] and Safari. Afterit sends a TLS ClientHello, if Mozilla Firefox finds that the server is unable to complete the handshake, it willattempt to fall back to using SSL 3.0 with an SSL 3.0 ClientHello in SSL 2.0 format to maximize the likelihood ofsuccessfully handshaking with older servers. Support for SSL 2.0 (and weak 40-bit and 56-bit ciphers) has beenremoved completely from Opera as of version 10.[2]

SSL 3.0SSL 3.0 improved upon SSL 2.0 by adding SHA-1 based ciphers and support for certificate authentication.From a security standpoint, SSL 3.0 should be considered less desirable than TLS 1.0. The SSL 3.0 cipher suiteshave a weaker key derivation process; half of the master key that is established is fully dependent on the MD5 hashfunction, which is not resistant to collisions and is, therefore, not considered secure. Under TLS 1.0, the master keythat is established depends on both MD5 and SHA-1 so its derivation process is not currently considered weak. It isfor this reason that SSL 3.0 implementations cannot be validated under FIPS 140-2.There are some attacks against the implementation rather than the protocol itself: In the earlier implementations,some CAs did not explicitly set basicConstraints CA=FALSE for leaf nodes. As a result, these leaf nodes could signrogue certificates. In addition, some early software (including IE6 and Konqueror) did not check this field altogether.This can be exploited for man-in-the-middle attack on all potential SSL connections.Some implementations(including older versions of Microsoft Cryptographic API, Network Security Services and GnuTLS) stop readingany characters that follow the null character in the name field of the certificate, which can be exploited to fool the

Transport Layer Security 40

client into reading the certificate as if it were one that came from the authentic site.(e.g., PayPal.com\0.badguy.com would be mistaken as the site of PayPal.com rather than badguy.com.)Browsersimplemented SSL/TLS protocol version fallback mechanisms for compatibility reasons. The protection offered bythe SSL/TLS protocols against a downgrade to a previous version by an active man-in-the-middle attack can berendered useless by such mechanisms.

TLSTLS has a variety of security measures:•• Protection against a downgrade of the protocol to a previous (less secure) version or a weaker cipher suite.• Numbering subsequent Application records with a sequence number and using this sequence number in the

message authentication codes (MACs).• Using a message digest enhanced with a key (so only a key-holder can check the MAC). The HMAC construction

used by most TLS cipher suites is specified in RFC 2104 (SSL 3.0 used a different hash-based MAC).•• The message that ends the handshake ("Finished") sends a hash of all the exchanged handshake messages seen by

both parties.• The pseudorandom function splits the input data in half and processes each one with a different hashing algorithm

(MD5 and SHA-1), then XORs them together to create the MAC. This provides protection even if one of thesealgorithms is found to be vulnerable.

TLS is the subject of active security research and both TLS attacks and counter-defences are evolving. Significantattacks against TLS are listed below:

Renegotiation attack

A vulnerability of the renegotiation procedure was discovered in August 2009 that can lead to plaintext injectionattacks against SSL 3.0 and all current versions of TLS. For example, it allows an attacker who can hijack an httpsconnection to splice their own requests into the beginning of the conversation the client has with the web server. Theattacker can't actually decrypt the client-server communication, so it is different from a typical man-in-the-middleattack. A short-term fix is for web servers to stop allowing renegotiation, which typically will not require otherchanges unless client certificate authentication is used. To fix the vulnerability, a renegotiation indication extensionwas proposed for TLS. It will require the client and server to include and verify information about previoushandshakes in any renegotiation handshakes. This extension has become a proposed standard and has been assignedthe number RFC 5746. The RFC has been implemented by several libraries.

Version rollback attacks

Modifications to the original protocols, like False Start (adopted and enabled by Google Chrome) or Snap Start,have been reported to introduce limited TLS protocol version rollback attacks or to allow modifications to the ciphersuite list sent by the client to the server (an attacker may be able to influence the cipher suite selection in an attemptto downgrade the cipher suite strength, to use either a weaker symmetric encryption algorithm or a weaker keyexchange). It has been shown in the Association for Computing Machinery (ACM) conference on computer andcommunications security that the False Start extension is at risk as in certain circumstances it could allow an attackerto recover the encryption keys offline and access the encrypted data.

Transport Layer Security 41

BEAST attack

On September 23, 2011 researchers Thai Duong and Juliano Rizzo demonstrated a proof of concept called BEAST(Browser Exploit Against SSL/TLS) using a Java applet to violate same origin policy constraints, for a long-knowncipher block chaining (CBC) vulnerability in TLS 1.0. Practical exploits had not been previously demonstrated forthis vulnerability, which was originally discovered by Phillip Rogaway in 2002. The vulnerability of the attack hadbeen fixed with TLS 1.1 in 2006, but TLS 1.1 had not seen wide adoption prior to this attack demonstration.Mozilla updated the development versions of their NSS libraries to mitigate BEAST-like attacks. NSS is used byMozilla Firefox and Google Chrome to implement SSL. Some web servers that have a broken implementation of theSSL specification may stop working as a result.Microsoft released Security Bulletin MS12-006 on January 10, 2012, which fixed the BEAST vulnerability bychanging the way that the Windows Secure Channel (SChannel) component transmits encrypted network packets.Users of Windows 7, Windows 8 and Windows Server 2008 R2 can enable use of TLS 1.1 and 1.2, but thisworkaround will fail if it is not supported by the other end of the connection and will result in a fall-back to TLS 1.0.As of October 2013, an estimated 69.5% (+4.4%) of web sites were supporting protocol variants vulnerable to theBEAST attack, 17.5% (-1.0%) vulnerable to the CRIME attack (see below), and 32.1% (-0.8%) with insecureciphers.

CRIME and BREACH attacks

The authors of the BEAST attack are also the creators of the later CRIME attack, which can allow an attacker torecover the content of web cookies when data compression is used along with TLS. When used to recover thecontent of secret authentication cookies, it allows an attacker to perform session hijacking on an authenticated websession.CRIME was further developed in 2013 into a hacking technique, dubbed BREACH, that also exploits the use of datacompression algorithms. A BREACH attack can extract login tokens, email addresses or other sensitive informationfrom TLS encrypted web traffic in as little as 30 seconds (depending on the number of bytes to be extracted),provided the attacker tricks the victim into visiting a malicious web link or is able to inject content into valid pagesthe user is visiting (ex: a wireless network under the control of the attacker). All versions of TLS and SSL are at riskfrom BREACH regardless of the encryption algorithm or cipher used. Unlike CRIME, which can be successfullydefended against by turning off TLS compression, BREACH exploits HTTP compression which cannot realisticallybe turned off, as virtually all web servers rely upon it to improve data transmission speeds for users. This is a knownlimitation of TLS as it is susceptible to chosen-plaintext attack against the application-layer data it was meant toprotect.

Padding attacks

Earlier TLS versions were vulnerable against the padding oracle attack discovered in 2002. A novel variant, calledthe Lucky Thirteen attack, was published in 2013. As of February 2013, TLS implementors were still working ondeveloping fixes to protect against this form of attack.

RC4 attacks

In spite of existing attacks on RC4 that break it, the cipher suites based on RC4 in SSL and TLS were consideredsecure because of how the cipher was used in these protocols. In 2011 RC4 suite was actually recommended as awork around for the BEAST attack.[3] In 2013 however there was an attack scenario proposed by AlFardan,Bernstein, Paterson, Poettering and Schuldt that uses newly discovered statistical biases in RC4 key table to recoverparts of plaintext with large number of TLS encryptions. A double-byte bias attack on RC4 in TLS and SSL thatrequires 13 × 220 encryptions to break RC4 was unveiled on 8 July 2013, and it was described as "feasible" in theaccompanying presentation at the 22nd USENIX Security Symposium on August 15, 2013.

Transport Layer Security 42

Truncation attack

A TLS truncation attack blocks a victim's account logout requests so that the user unknowingly remains logged intoa web service. When the request to sign out is sent, the attacker injects an unencrypted TCP FIN message (no moredata from sender) to close the connection. The server therefore doesn't receive the logout request and is unaware ofthe abnormal termination.Published in July of 2013, the attack causes web services such as Gmail and Hotmail to display a page that informsthe user that they have successfully signed-out, while ensuring that the user's browser maintains authorization withthe service, allowing an attacker with subsequent access to the browser to access and take over control of the user'slogged-in account. The attack does not rely on installing malware on the victim's computer; attackers need only placethemselves between the victim and the web server (e.g., by setting up a rogue wireless hotspot).

Perfect forward secrecyPerfect forward secrecy is a property of cryptographic systems which ensures that a session key derived from a set ofpublic and private keys will not be compromised if one of the private keys is compromised in the future. Animplementation of TLS can provide perfect forward secrecy by requiring the use of ephemeral Diffie-Hellman keyexchange to establish session keys, and some notable TLS implementations do so exclusively: e.g., Gmail and otherGoogle HTTPS services that use OpenSSL. However, many web servers providing TLS are not configured toimplement such restrictions. Without perfect forward secrecy, if the server's private key is compromised, not onlywill all future TLS-encrypted sessions using that server certificate be compromised, but also any past sessions thatused it as well (provided of course that these past sessions were intercepted and stored at the time of transmission).[4]

In practice, unless a web service uses Diffie-Hellman key exchange to implement perfect forward secrecy, all of theencrypted web traffic to and from that service can be decrypted by a third party if it obtains the server's master(private) key; e.g., by means of a court order.Even where Diffie-Hellman key exchange is implemented, server-side session management mechanisms can impactforward secrecy. The use of TLS session tickets (a TLS extension) causes the session to be protected byAES128-CBC-SHA256 regardless of any other negotiated TLS parameters, including perfect forward secrecyciphersuites, and the long-lived TLS session ticket keys defeat the attempt to implement forward secrecy.

Dealing with RC4 and BEASTBecause of the BEAST attack, administrators were advised to use RC4 on their web servers.[5] The discoveredvulnerability in RC4 makes this complicated.[6] As of July 2013 (http:/ / en. wikipedia. org/ w/ index.php?title=Transport_Layer_Security& action=edit) the best choice is to only allow TLS 1.1 and TLS 1.2, but Firefoxhas support for TLS 1.1 disabled by default and no support for TLS 1.2, and Opera and Internet Explorer havesupport for TLS 1.1 and TLS 1.2 but they are disabled by default. In most web servers, only one cipher can beassigned as the preferred cipher. Choosing RC4 is still the best choice for TLS 1.0, but not for TLS 1.1 and TLS 1.2.Choosing AES (using CBC or preferably GCM mode in TLS 1.2) is secure for TLS 1.1 and TLS 1.2, but not for TLS1.0 due to the BEAST attack.PolarSSL since version 1.2.7,[7] allows an application to select a ciphersuite based on the used protocol. TheHiawatha webserver version 9.1 has implemented this: for SSL 3.0 or TLS 1.0, the RC4 cipher will be used; for TLS1.1 or TLS 1.2, AES or Camellia will be used.[8][9]

Transport Layer Security 43

Protocol detailsThe TLS protocol exchanges records - which encapsulate the data to be exchanged in a specific format (see below).Each record can be compressed, padded, appended with a message authentication code (MAC), or encrypted, alldepending on the state of the connection. Each record has a content type field that designates the type of dataencapsulated, a length field and a TLS version field. The data encapsulated may be control or procedural messagesof the TLS itself, or simply the application data needed to be transferred by TLS. The specifications (cipher suite,keys etc.) required to exchange application data by TLS, are agreed upon in the "TLS handshake" between the clientrequesting the data and the server responding to requests. The protocol therefore defines both the structure ofpayloads transferred in TLS and the procedure to establish and monitor the transfer.

TLS handshakeWhen the connection starts, the record encapsulates a "control" protocol — the handshake messaging protocol (content type 22). This protocol is used to exchange all the information required by both sides for the exchange of theactual application data by TLS. It defines the messages formatting or containing this information and the order oftheir exchange. These may vary according to the demands of the client and server i.e. there are several possibleprocedures to setup the connection. This initial exchange results in a successful TLS connection (both parties readyto transfer application data with TLS) or an alert message (as specified below).

Basic TLS handshake

A simple connection example follows, illustrating a handshake where the server (but not the client) is authenticatedby its certificate:1.1. Negotiation phase:

• A client sends a ClientHello message specifying the highest TLS protocol version it supports, a randomnumber, a list of suggested CipherSuites and suggested compression methods. If the client is attempting toperform a resumed handshake, it may send a session ID.

• The server responds with a ServerHello message, containing the chosen protocol version, a random number,CipherSuite and compression method from the choices offered by the client. To confirm or allow resumedhandshakes the server may send a session ID. The chosen protocol version should be the highest that both theclient and server support. For example, if the client supports TLS1.1 and the server supports TLS1.2, TLS1.1should be selected; SSL 3.0 should not be selected.

• The server sends its Certificate message (depending on the selected cipher suite, this may be omitted by theserver).[10]

• The server sends a ServerHelloDone message, indicating it is done with handshake negotiation.• The client responds with a ClientKeyExchange message, which may contain a PreMasterSecret, public key,

or nothing. (Again, this depends on the selected cipher.) This PreMasterSecret is encrypted using the publickey of the server certificate.

• The client and server then use the random numbers and PreMasterSecret to compute a common secret, calledthe "master secret". All other key data for this connection is derived from this master secret (and the client- andserver-generated random values), which is passed through a carefully designed pseudorandom function.

2. The client now sends a ChangeCipherSpec record, essentially telling the server, "Everything I tell you from nowon will be authenticated (and encrypted if encryption parameters were present in the server certificate)." TheChangeCipherSpec is itself a record-level protocol with content type of 20.• Finally, the client sends an authenticated and encrypted Finished message, containing a hash and MAC over

the previous handshake messages.• The server will attempt to decrypt the client's Finished message and verify the hash and MAC. If the

decryption or verification fails, the handshake is considered to have failed and the connection should be torn

Transport Layer Security 44

down.3. Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I tell you from now on will be

authenticated (and encrypted, if encryption was negotiated)."• The server sends its authenticated and encrypted Finished message.•• The client performs the same decryption and verification.

4. Application phase: at this point, the "handshake" is complete and the application protocol is enabled, with contenttype of 23. Application messages exchanged between client and server will also be authenticated and optionallyencrypted exactly like in their Finished message. Otherwise, the content type will return 25 and the client will notauthenticate.

Client-authenticated TLS handshake

The following full example shows a client being authenticated (in addition to the server like above) via TLS usingcertificates exchanged between both peers.1.1. Negotiation Phase:

• A client sends a ClientHello message specifying the highest TLS protocol version it supports, a randomnumber, a list of suggested cipher suites and compression methods.

• The server responds with a ServerHello message, containing the chosen protocol version, a random number,cipher suite and compression method from the choices offered by the client. The server may also send asession id as part of the message to perform a resumed handshake.

• The server sends its Certificate message (depending on the selected cipher suite, this may be omitted by theserver).

• The server requests a certificate from the client, so that the connection can be mutually authenticated, using aCertificateRequest message.

• The server sends a ServerHelloDone message, indicating it is done with handshake negotiation.• The client responds with a Certificate message, which contains the client's certificate.• The client sends a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or

nothing. (Again, this depends on the selected cipher.) This PreMasterSecret is encrypted using the public keyof the server certificate.

• The client sends a CertificateVerify message, which is a signature over the previous handshake messagesusing the client's certificate's private key. This signature can be verified by using the client's certificate's publickey. This lets the server know that the client has access to the private key of the certificate and thus owns thecertificate.

• The client and server then use the random numbers and PreMasterSecret to compute a common secret, calledthe "master secret". All other key data for this connection is derived from this master secret (and the client- andserver-generated random values), which is passed through a carefully designed pseudorandom function.

2. The client now sends a ChangeCipherSpec record, essentially telling the server, "Everything I tell you from nowon will be authenticated (and encrypted if encryption was negotiated). " The ChangeCipherSpec is itself arecord-level protocol and has type 20 and not 22.• Finally, the client sends an encrypted Finished message, containing a hash and MAC over the previous

handshake messages.• The server will attempt to decrypt the client's Finished message and verify the hash and MAC. If the

decryption or verification fails, the handshake is considered to have failed and the connection should be torndown.

3. Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I tell you from now on will beauthenticated (and encrypted if encryption was negotiated). "• The server sends its own encrypted Finished message.

Transport Layer Security 45

•• The client performs the same decryption and verification.4. Application phase: at this point, the "handshake" is complete and the application protocol is enabled, with content

type of 23. Application messages exchanged between client and server will also be encrypted exactly like in theirFinished message.

Resumed TLS handshake

Public key operations (e.g., RSA) are relatively expensive in terms of computational power. TLS provides a secureshortcut in the handshake mechanism to avoid these operations: resumed sessions. Resumed sessions areimplemented using session IDs or session tickets.Apart from the performance benefit, resumed sessions can also be used for single sign-on as it is guaranteed thatboth the original session as well as any resumed session originate from the same client. This is of particularimportance for the FTP over TLS/SSL protocol which would otherwise suffer from a man in the middle attack inwhich an attacker could intercept the contents of the secondary data connections.

Session IDs

In an ordinary full handshake, the server sends a session id as part of the ServerHello message. The client associatesthis session id with the server's IP address and TCP port, so that when the client connects again to that server, it canuse the session id to shortcut the handshake. In the server, the session id maps to the cryptographic parameterspreviously negotiated, specifically the "master secret". Both sides must have the same "master secret" or the resumedhandshake will fail (this prevents an eavesdropper from using a session id). The random data in the ClientHello andServerHello messages virtually guarantee that the generated connection keys will be different than in the previousconnection. In the RFCs, this type of handshake is called an abbreviated handshake. It is also described in theliterature as a restart handshake.1.1. Negotiation phase:

• A client sends a ClientHello message specifying the highest TLS protocol version it supports, a randomnumber, a list of suggested cipher suites and compression methods. Included in the message is the session idfrom the previous TLS connection.

• The server responds with a ServerHello message, containing the chosen protocol version, a random number,cipher suite and compression method from the choices offered by the client. If the server recognizes thesession id sent by the client, it responds with the same session id. The client uses this to recognize that aresumed handshake is being performed. If the server does not recognize the session id sent by the client, itsends a different value for its session id. This tells the client that a resumed handshake will not be performed.At this point, both the client and server have the "master secret" and random data to generate the key data to beused for this connection.

2. The server now sends a ChangeCipherSpec record, essentially telling the client, "Everything I tell you from nowon will be encrypted. " The ChangeCipherSpec is itself a record-level protocol and has type 20 and not 22.• Finally, the server sends an encrypted Finished message, containing a hash and MAC over the previous

handshake messages.• The client will attempt to decrypt the server's Finished message and verify the hash and MAC. If the

decryption or verification fails, the handshake is considered to have failed and the connection should be torndown.

3. Finally, the client sends a ChangeCipherSpec, telling the server, "Everything I tell you from now on will beencrypted. "• The client sends its own encrypted Finished message.•• The server performs the same decryption and verification.

Transport Layer Security 46

4. Application phase: at this point, the "handshake" is complete and the application protocol is enabled, with contenttype of 23. Application messages exchanged between client and server will also be encrypted exactly like in theirFinished message.

Session tickets

RFC 5077 extends TLS via use of session tickets, instead of session IDs. It defines a way to resume a TLS sessionwithout requiring session-specific state at the TLS server.One particular weakness of this method is that it always limits encryption and authentication security of the TLSconnection to AES128-CBC-SHA256, no matter what other TLS parameters were negotiated. Of particular concernis OpenSSL's storage of the keys in an application-wide context (SSL_CTX), i.e. for the life of the application, andnot allowing for re-keying of the AES128-CBC-SHA256 TLS session tickets without resetting the application-wideOpenSSL context (which is uncommon, error-prone and often requires manual administrative intervention).

TLS recordThis is the general format of all TLS records.

+ Byte +0 Byte +1 Byte +2 Byte +3

Byte0

Content type

Bytes1..4

Version Length

(Major) (Minor) (bits 15..8) (bits 7..0)

Bytes5..(m-1)

Protocol message(s)

Bytesm..(p-1)

MAC (optional)

Bytesp..(q-1)

Padding (block ciphers only)

Content typeThis field identifies the Record Layer Protocol Type contained in this Record.

Content types

Hex Dec Type

0x14 20 ChangeCipherSpec

0x15 21 Alert

0x16 22 Handshake

0x17 23 Application

VersionThis field identifies the major and minor version of TLS for the contained message. For a ClientHellomessage, this need not be the highest version supported by the client.

Transport Layer Security 47

Versions

MajorVersion

MinorVersion

Version Type

3 0 SSL 3.0

3 1 TLS 1.0

3 2 TLS 1.1

3 3 TLS 1.2

LengthThe length of Protocol message(s), not to exceed 214 bytes (16 KiB).

Protocol message(s)One or more messages identified by the Protocol field. Note that this field may be encrypted depending on thestate of the connection.

MAC and PaddingA message authentication code computed over the Protocol message, with additional key material included.Note that this field may be encrypted, or not included entirely, depending on the state of the connection.No MAC or Padding can be present at end of TLS records before all cipher algorithms and parameters havebeen negotiated and handshaked and then confirmed by sending a CipherStateChange record (see below) forsignalling that these parameters will take effect in all further records sent by the same peer.

Handshake protocol

Most messages exchanged during the setup of the TLS session are based on this record, unless an error or warningoccurs and needs to be signaled by an Alert protocol record (see below), or the encryption mode of the session ismodified by another record (see ChangeCipherSpec protocol below).

+ Byte +0 Byte +1 Byte +2 Byte +3

Byte0

22

Bytes1..4

Version Length

(Major) (Minor) (bits 15..8) (bits 7..0)

Bytes5..8

Message type Handshake message data length

(bits 23..16) (bits 15..8) (bits 7..0)

Bytes9..(n-1)

Handshake message data

Bytesn..(n+3)

Message type Handshake message data length

(bits 23..16) (bits 15..8) (bits 7..0)

Bytes(n+4)..

Handshake message data

Message typeThis field identifies the Handshake message type.

Transport Layer Security 48

Message Types

Code Description

0 HelloRequest

1 ClientHello

2 ServerHello

11 Certificate

12 ServerKeyExchange

13 CertificateRequest

14 ServerHelloDone

15 CertificateVerify

16 ClientKeyExchange

20 Finished

Handshake message data lengthThis is a 3-byte field indicating the length of the handshake data, not including the header.

Note that multiple Handshake messages may be combined within one record.

Alert protocol

This record should normally not be sent during normal handshaking or application exchanges. However, thismessage can be sent at any time during the handshake and up to the closure of the session. If this is used to signal afatal error, the session will be closed immediately after sending this record, so this record is used to give a reason forthis closure. If the alert level is flagged as a warning, the remote can decide to close the session if it decides that thesession is not reliable enough for its needs (before doing so, the remote may also send its own signal).

+ Byte +0 Byte +1 Byte +2 Byte +3

Byte0

21

Bytes1..4

Version Length

(Major) (Minor) 0 2

Bytes5..6

Level Description

Bytes7..(p-1)

MAC (optional)

Bytesp..(q-1)

Padding (block ciphers only)

LevelThis field identifies the level of alert. If the level is fatal, the sender should close the session immediately.Otherwise, the recipient may decide to terminate the session itself, by sending its own fatal alert and closingthe session itself immediately after sending it. The use of Alert records is optional, however if it is missingbefore the session closure, the session may be resumed automatically (with its handshakes).Normal closure of a session after termination of the transported application should preferably be alerted with at least the Close notify Alert type (with a simple warning level) to prevent such automatic resume of a new session. Signalling explicitly the normal closure of a secure session before effectively closing its transport

Transport Layer Security 49

layer is useful to prevent or detect attacks (like attempts to truncate the securely transported data, if itintrinsically does not have a predetermined length or duration that the recipient of the secured data mayexpect).

Alert level types

Code Level type Connection state

1 warning connection or security may be unstable.

2 fatal connection or security may be compromised, or an unrecoverable error has occurred.

DescriptionThis field identifies which type of alert is being sent.

Alert description types

Code Description Level types Note

0 Close notify warning/fatal

10 Unexpected message fatal

20 Bad record MAC fatal Possibly a bad SSL implementation, or payload has been tampered with e. g. FTPfirewall rule on FTPS server.

21 Decryption failed fatal TLS only, reserved

22 Record overflow fatal TLS only

30 Decompression failure fatal

40 Handshake failure fatal

41 No certificate warning/fatal SSL 3.0 only, reserved

42 Bad certificate warning/fatal

43 Unsupported certificate warning/fatal E. g. certificate has only Server authentication usage enabled and is presented as aclient certificate

44 Certificate revoked warning/fatal

45 Certificate expired warning/fatal Check server certificate expire also check no certificate in the chain presented hasexpired

46 Certificate unknown warning/fatal

47 Illegal parameter fatal

48 Unknown CA (Certificateauthority)

fatal TLS only

49 Access denied fatal TLS only - E. g. no client certificate has been presented (TLS: Blank certificatemessage or SSLv3: No Certificate alert), but server is configured to require one.

50 Decode error fatal TLS only

51 Decrypt error warning/fatal TLS only

60 Export restriction fatal TLS only, reserved

70 Protocol version fatal TLS only

71 Insufficient security fatal TLS only

80 Internal error fatal TLS only

90 User canceled fatal TLS only

Transport Layer Security 50

100 No renegotiation warning TLS only

110 Unsupported extension warning TLS only

111 Certificate unobtainable warning TLS only

112 Unrecognized name warning TLS only; client's Server Name Indicator specified a hostname not supported by theserver

113 Bad certificate status response fatal TLS only

114 Bad certificate hash value fatal TLS only

115 Unknown PSK identity (used inTLS-PSK and TLS-SRP)

fatal TLS only

ChangeCipherSpec protocol

+ Byte +0 Byte +1 Byte +2 Byte +3

Byte0

20

Bytes1..4

Version Length

(Major) (Minor) 0 1

Byte5

CCS protocol type

CCS protocol typeCurrently only 1.

Application protocol

+ Byte +0 Byte +1 Byte +2 Byte +3

Byte0

23

Bytes1..4

Version Length

(Major) (Minor) (bits 15..8) (bits 7..0)

Bytes5..(m-1)

Application data

Bytesm..(p-1)

MAC (optional)

Bytesp..(q-1)

Padding (block ciphers only)

LengthLength of Application data (excluding the protocol header and including the MAC and padding trailers)

MAC20 bytes for the SHA-1-based HMAC, 16 bytes for the MD5-based HMAC.

PaddingVariable length; last byte contains the padding length.

Transport Layer Security 51

Support for name-based virtual serversFrom the application protocol point of view, TLS belongs to a lower layer, although the TCP/IP model is too coarseto show it. This means that the TLS handshake is usually (except in the STARTTLS case) performed before theapplication protocol can start. The name-based virtual server feature being provided by the application layer, allco-hosted virtual servers share the same certificate because the server has to select and send a certificate immediatelyafter the ClientHello message. This is a big problem in hosting environments because it means either sharing thesame certificate among all customers or using a different IP address for each of them.There are two known workarounds provided by X.509:• If all virtual servers belong to the same domain, a wildcard certificate can be used. Besides the loose host name

selection that might be a problem or not, there is no common agreement about how to match wildcard certificates.Different rules are applied depending on the application protocol or software used.

•• Add every virtual host name in the subjectAltName extension. The major problem being that the certificate needsto be reissued whenever a new virtual server is added.

In order to provide the server name, RFC 4366 Transport Layer Security (TLS) Extensions allow clients to include aServer Name Indication extension (SNI) in the extended ClientHello message. This extension hints the serverimmediately which name the client wishes to connect to, so the server can select the appropriate certificate to send tothe client.

StandardsThe current approved version of TLS is version 1.2, which is specified in:• RFC 5246: “The Transport Layer Security (TLS) Protocol Version 1.2”.The current standard replaces these former versions, which are now considered obsolete:• RFC 2246: “The TLS Protocol Version 1.0”.• RFC 4346: “The Transport Layer Security (TLS) Protocol Version 1.1”.as well as the never standardized SSL 2.0 and 3.0:• Hickman, Kipp E.B. (April 1995). "The SSL Protocol" (http:/ / tools. ietf. org/ html/

draft-hickman-netscape-ssl-00). Retrieved July 31, 2013. This Internet Draft defines the now completely brokenSSL 2.0.

• RFC 6101: “The Secure Sockets Layer (SSL) Protocol Version 3.0”.Other RFCs subsequently extended TLS.Extensions to TLS 1.0 include:• RFC 2595: “Using TLS with IMAP, POP3 and ACAP”. Specifies an extension to the IMAP, POP3 and ACAP

services that allow the server and client to use transport-layer security to provide private, authenticatedcommunication over the Internet.

• RFC 2712: “Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)”. The 40-bit cipher suitesdefined in this memo appear only for the purpose of documenting the fact that those cipher suite codes havealready been assigned.

• RFC 2817: “Upgrading to TLS Within HTTP/1.1”, explains how to use the Upgrade mechanism in HTTP/1.1 toinitiate Transport Layer Security (TLS) over an existing TCP connection. This allows unsecured and securedHTTP traffic to share the same well known port (in this case, http: at 80 rather than https: at 443).

• RFC 2818: “HTTP Over TLS”, distinguishes secured traffic from insecure traffic by the use of a different 'serverport'.

• RFC 3207: “SMTP Service Extension for Secure SMTP over Transport Layer Security”. Specifies an extension to the SMTP service that allows an SMTP server and client to use transport-layer security to provide private,

Transport Layer Security 52

authenticated communication over the Internet.• RFC 3268: “AES Ciphersuites for TLS”. Adds Advanced Encryption Standard (AES) cipher suites to the

previously existing symmetric ciphers.• RFC 3546: “Transport Layer Security (TLS) Extensions”, adds a mechanism for negotiating protocol extensions

during session initialisation and defines some extensions. Made obsolete by RFC 4366.• RFC 3749: “Transport Layer Security Protocol Compression Methods”, specifies the framework for compression

methods and the DEFLATE compression method.• RFC 3943: “Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS)”.• RFC 4132: “Addition of Camellia Cipher Suites to Transport Layer Security (TLS)”.• RFC 4162: “Addition of SEED Cipher Suites to Transport Layer Security (TLS)”.• RFC 4217: “Securing FTP with TLS”.• RFC 4279: “Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)”, adds three sets of new cipher

suites for the TLS protocol to support authentication based on pre-shared keys.Extensions to TLS 1.1 include:• RFC 4347: “Datagram Transport Layer Security” specifies a TLS variant that works over datagram protocols

(such as UDP).• RFC 4366: “Transport Layer Security (TLS) Extensions” describes both a set of specific extensions and a generic

extension mechanism.• RFC 4492: “Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)”.• RFC 4680: “TLS Handshake Message for Supplemental Data”.• RFC 4681: “TLS User Mapping Extension”.• RFC 4785: “Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS)”.• RFC 5054: “Using the Secure Remote Password (SRP) Protocol for TLS Authentication”. Defines the TLS-SRP

ciphersuites.• RFC 5077: “Transport Layer Security (TLS) Session Resumption without Server-Side State”.• RFC 5081: “Using OpenPGP Keys for Transport Layer Security (TLS) Authentication”, obsoleted by RFC 6091.Extensions to TLS 1.2 include:• RFC 5288: “AES Galois Counter Mode (GCM) Cipher Suites for TLS”.• RFC 5289: “TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)”.• RFC 5746: “Transport Layer Security (TLS) Renegotiation Indication Extension”.• RFC 5878: “Transport Layer Security (TLS) Authorization Extensions”.• RFC 6066: “Transport Layer Security (TLS) Extensions: Extension Definitions”, includes Server Name Indication

and OCSP stapling.• RFC 6091: “Using OpenPGP Keys for Transport Layer Security (TLS) Authentication“.• RFC 6176: “Prohibiting Secure Sockets Layer (SSL) Version 2.0”.• RFC 6209: “Addition of the ARIA Cipher Suites to Transport Layer Security (TLS)”.• RFC 6460: “Suite B Profile for Transport Layer Security (TLS)”.Encapsulations of TLS include:• RFC 5216: "The EAP-TLS Authentication Protocol"

Transport Layer Security 53

References[1] "Opera 9.5 for Windows Changelog" (http:/ / www. opera. com/ docs/ changelogs/ windows/ 950/ ) at Opera.com: "Disabled SSL v2 and

weak ciphers."[2] "Opera 10 for Windows changelog" (http:/ / www. opera. com/ docs/ changelogs/ windows/ 1000/ ) at Opera.com: "Removed support for SSL

v2 and weak ciphers"[3] security - Safest ciphers to use with the BEAST? (TLS 1.0 exploit) I've read that RC4 is immune - Server Fault (http:/ / serverfault. com/

questions/ 315042/ )[4] Discussion on the TLS mailing list in October 2007 (http:/ / www1. ietf. org/ mail-archive/ web/ tls/ current/ msg02134. html)[5] mitigating-the-beast-attack-on-tls (https:/ / community. qualys. com/ blogs/ securitylabs/ 2011/ 10/ 17/ mitigating-the-beast-attack-on-tls)[6] rc4-in-tls-is-broken-now-what (https:/ / community. qualys. com/ blogs/ securitylabs/ 2013/ 03/ 19/ rc4-in-tls-is-broken-now-what)[7] version 1.2.7 (https:/ / polarssl. org/ tech-updates/ releases/ polarssl-1. 2. 7-released)[8] Hiawatha webserver (http:/ / www. hiawatha-webserver. org/ )[9] version 9.1 (http:/ / www. hiawatha-webserver. org/ weblog/ 55)[10] These certificates are currently X.509, but there is also a draft specifying the use of OpenPGP based certificates.

Further reading• Wagner, David; Schneier, Bruce (November 1996). "Analysis of the SSL 3.0 Protocol" (http:/ / www. schneier.

com/ paper-ssl. pdf). The Second USENIX Workshop on Electronic Commerce Proceedings. USENIX Press.pp. 29–40.

• Eric Rescorla (2001). SSL and TLS: Designing and Building Secure Systems. United States: Addison-Wesley PubCo. ISBN 0-201-61598-3.

• Stephen A. Thomas (2000). SSL and TLS essentials securing the Web. New York: Wiley. ISBN 0-471-38354-6.• Bard, Gregory (2006). "A Challenging But Feasible Blockwise-Adaptive Chosen-Plaintext Attack On Ssl" (http:/

/ eprint. iacr. org/ 2006/ 136). International Association for Cryptologic Research (136). Retrieved 2011-09-23.• Canvel, Brice. "Password Interception in a SSL/TLS Channel" (http:/ / lasecwww. epfl. ch/ memo/ memo_ssl.

shtml). Retrieved 2007-04-20.• IETF Multiple Authors. "RFC of change for TLS Renegotiation" (http:/ / tools. ietf. org/ html/ rfc5746). Retrieved

2009-12-11.• Creating VPNs with IPsec and SSL/TLS (http:/ / www. linuxjournal. com/ article/ 9916) Linux Journal article by

Rami Rosen

External links• SSL 2 specification (http:/ / www. mozilla. org/ projects/ security/ pki/ nss/ ssl/ draft02. html) (published 1994)• Early drafts of SSL 3.0 specification (http:/ / tools. ietf. org/ html/ draft-freier-ssl-version3-00) (published 1995)• The Secure Sockets Layer (SSL) Protocol Version 3.0 (2011) (http:/ / tools. ietf. org/ html/ rfc6101)• The IETF (Internet Engineering Task Force) TLS Workgroup (http:/ / www. ietf. org/ html. charters/ tls-charter.

html)• SSL tutorial (http:/ / www2. rad. com/ networks/ 2001/ ssl/ index. htm)Wikipedia:Link rot• OWASP: Transport Layer Protection Cheat Sheet (http:/ / www. owasp. org/ index.

php?title=Transport_Layer_Protection_Cheat_Sheet)• A talk on SSL/TLS that tries to explain things in terms that people might understand. (http:/ / computing. ece. vt.

edu/ ~jkh/ Understanding_SSL_TLS. pdf)• SSL: Foundation for Web Security (http:/ / www. cisco. com/ web/ about/ ac123/ ac147/ archived_issues/ ipj_1-1/

ssl. html)• Various SSL tools including parsers, certificate lookup and manager (http:/ / www. ssltools. com/ )• TLS test server for checking client (http:/ / mikestoolbox. com/ home. html)• TLS Renegotiation Vulnerability - IETF Tools (http:/ / tools. ietf. org/ agenda/ 76/ slides/ tls-7. pdf)

Transport Layer Security 54

This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 andincorporated under the "relicensing" terms of the GFDL, version 1.3 or later.

Social VPNA social VPN is a virtual private network that is created among individual peers, automatically, based onrelationships established by them through a social networking service. A social VPN aims at providing peer-to-peer(P2P) network connectivity between a user and his or her friends, in an easy to set up manner that hides from theusers the complexity in setting up and maintaining authenticated/encrypted end-to-end VPN tunnels.

ArchitectureAn architecture of a social VPN is based on a centralized infrastructure where users authenticate, discover theirfriends and exchange cryptographic public keys, and a P2P overlay which is used to route messages between VPNendpoints.[1] The approach is

Packet capture and injectionA social VPN uses a virtual network interface (such as TUN/TAP devices in Windows and Unix systems) to captureand inject IP packets from a host. Once captured, packets are encrypted, encapsulated, and routed over an overlaynetwork.

SecurityA social VPN uses online social networks to distribute public keys and advertise node address to friends. Theacquired public keys are used to establish encrypted communication between two endpoints. Symmetric keys areexchanged during the process of establishing an end-to-end link by two social VPN peers.

RoutingRouting in the social VPN is peer-to-peer. One approach that has been implemented uses a structured P2P system forsending IP packets encapsulated in overlay messages from a source to destination.

Private IP address spaceA social VPN uses dynamic IP address assignment and translation to avoid collision with existing (private) addressspaces of end hosts, and to allow the system to scale to the number of users that today's successful online socialnetwork services serve (tens of millions). Users are able to connect directly only to a small subset of the total numberof users of such a service, where the subset is determined by their established relationships.

Social VPN 55

NamingA social VPN uses names derived from the social network service to automatically assign host names to endpoints.These names are translated to virtual private IP addresses in the overlay by a loop-back DNS virtual server.

Related systems• The MIT Unmanaged Internet Architecture[2] (UIA)provides ad hoc, zero-configuration routing infrastructure for

mobile devices, but the ad hoc connections are not established through a social networking infrastructure.[3]

• "Friend Net" is a similar concept put forth in a 2002 blog entry.[4]

• Hamachi is a zero-configuration VPN which uses a security architecture different from that of social VPN.[5] Theleafnetworks VPN also supports the creation of networks using the Facebook API.

SoftwareAn open-source social VPN implementation based on the Facebook social network service and the Brunet P2Poverlay is available for Windows and Linux systems under MIT license. It creates direct point-to-point secureconnections between computers with the help of online social networks, and supports transparent traversal of NATs.It uses the P2P overlay to create direct VPN connections between pairs of computers (nodes). To establish aconnection, two nodes advertise their P2P node address (as well as public keys for secure communication) to eachother through an online social network. Once each node acquires the node address (and public keys) of the othernode, an IP-to-nodeAddress mapping is created and IP packets can be routed through the VPN tunnel.

References[1] R. Figueiredo, P. O. Boykin, P. St. Juste, D. Wolinsky, "SocialVPNs: Integrating Overlay and Social Networks for Seamless P2P

Networking" (http:/ / byron. acis. ufl. edu/ papers/ cops08. pdf), in Proceedings of IEEE WETICE/COPS, Rome, Italy, June 2008.[2] Unmanaged Internet Architecture (http:/ / pdos. csail. mit. edu/ uia/ )[3] Bryan Ford, Jacob Strauss, Chris Lesniewski-Laas, Sean Rhea, Frans Kaashoek, and Robert Morris, "Persistent Personal Names for Globally

Connected Mobile Devices" (http:/ / www. pdos. lcs. mit. edu/ papers/ uia:osdi06. pdf), in Proceedings of the 7th USENIX Symposium onOperating Systems Design and Implementation (OSDI '06), Seattle, WA, November 2006.

[4] Lucas Gonze "Friendnet" (http:/ / blogs. oreilly. com/ digitalmedia/ 2002/ 12/ friendnet. html), blog entry (2002-12-15). Retrieved on2008-09-23.

[5] LogMeIn Hamachi Security Architecture (https:/ / secure. logmein. com/ products/ hamachi/ securityarchitecture. asp).

External links• socialvpn.org (http:/ / www. socialvpn. org/ )• We Are Hidden, Social VPN (http:/ / wearehidden. tumblr. com/ post/ 26560696516/ social-vpn)

OpenVPN 56

OpenVPN

OpenVPN

Original author(s) James Yonan

Developer(s) OpenVPN project / OpenVPN Technologies, Inc.

Initial release 1.1.0 / April 10, 2002[1]

Stable release 2.3.2 (June 3, 2013) [±] [2]

Preview release 2.x (Git HEAD) (Every Sunday 05:00 GMT -5 Main [3] Mirror [4]) [±] [5]

Platform Cross-platform

Type VPN

License GNU GPL

Website openvpn.net/index.php/open-source.html [6]

OpenVPN is an open source software application that implements virtual private network (VPN) techniques forcreating secure point-to-point or site-to-site connections in routed or bridged configurations and remote accessfacilities. It uses a custom security protocol that utilizes SSL/TLS for key exchange. It is capable of traversingnetwork address translators (NATs) and firewalls. It was written by James Yonan and is published under the GNUGeneral Public License (GPL).[7]

OpenVPN allows peers to authenticate each other using a pre-shared secret key, certificates, or username/password.When used in a multiclient-server configuration, it allows the server to release an authentication certificate for everyclient, using signature and Certificate authority. It uses the OpenSSL encryption library extensively, as well as theSSLv3/TLSv1 protocol, and contains many security and control features.

Architecture

EncryptionOpenVPN uses the OpenSSL library to provide encryption of both the data and control channels. It lets OpenSSL doall the encryption and authentication work, allowing OpenVPN to use all the ciphers available in the OpenSSLpackage. It can also use the HMAC packet authentication feature to add an additional layer of security to theconnection (referred to as an "HMAC Firewall" by the creator). It can also use hardware acceleration to get betterencryption performance.[8][9] Support for PolarSSL is available starting from version 2.3.[10]

AuthenticationOpenVPN has several ways to authenticate peers to each another. OpenVPN offers pre-shared keys,certificate-based, and username/password-based authentication. Preshared secret key is the easiest, with certificatebased being the most robust and feature-rich. In version 2.0 username/password authentications can be enabled, bothwith or without certificates. However to make use of username/password authentications, OpenVPN depends onthird-party modules. See the Extensibility paragraph for more info.

OpenVPN 57

NetworkingOpenVPN can run over User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) transports,multiplexing created SSL tunnels on a single TCP/UDP port[11] (RFC 3948 [12] for UDP).[13] It has the ability towork through most proxy servers (including HTTP) and is good at working through Network address translation(NAT) and getting out through firewalls. The server configuration has the ability to "push" certain networkconfiguration options to the clients. These include IP addresses, routing commands, and a few connection options.OpenVPN offers two types of interfaces for networking via the Universal TUN/TAP driver. It can create either alayer-3 based IP tunnel (TUN), or a layer-2 based Ethernet TAP that can carry any type of Ethernet traffic.OpenVPN can optionally use the LZO compression library to compress the data stream. Port 1194 is the officialIANA assigned port number for OpenVPN. Newer versions of the program now default to that port. A feature in the2.0 version allows for one process to manage several simultaneous tunnels, as opposed to the original "one tunnel perprocess" restriction on the 1.x series.OpenVPN's use of common network protocols (TCP and UDP) makes it a desirable alternative to IPsec in situationswhere an ISP may block specific VPN protocols in order to force users to subscribe to a higher-priced, "businessgrade," service tier. Wikipedia:AUDIENCE

SecurityOpenVPN offers several internal security features. It runs in userspace, instead of requiring IP stack (and thereforekernel) operation. OpenVPN has the ability to drop root privileges, use mlockall [14] to prevent swapping sensitivedata to disk, enter a chroot jail after initialization and apply a SELinux context after initialization.OpenVPN runs a custom security protocol based on SSL and TLS. OpenVPN offers support of smart cards viaPKCS#11 based cryptographic tokens.

ExtensibilityOpenVPN can be extended with third-party plug-ins or scripts which can be called at defined entry points.[15] Thepurpose of this is often to extend OpenVPN with more advanced logging, enhanced authentication with usernameand passwords, dynamic firewall updates, RADIUS integration and so on. The plug-ins are dynamically loadablemodules, usually written in C, while the scripts interface can execute any scripts or binaries available to OpenVPN.In the OpenVPN source code there are some examples of such plug-ins, including a PAM authentication plug-in.Several third party plug-ins also exist to authenticate against LDAP or SQL databases such as SQLite and MySQL.There is an overview over many of these extensions in the related project wiki page [16] for the OpenVPNcommunity.

PlatformsIt is available on Solaris, Linux, OpenBSD, FreeBSD, NetBSD, QNX, Mac OS X, and Windows 2000/XP/Vista/7.While some mobile phone OSes (Palm OS, etc.) do not support OpenVPN, it is available for Maemo, WindowsMobile 6.5 and below, iOS 3GS+ devices, jailbroken iOS 3.1.2+ devices, Android 4.0+ devices, and Androiddevices that have had the Cyanogenmod aftermarket firmware flashed[17] or have the correct kernel module installed.It is not a "web-based" VPN, meaning that it is not shown as a web page such as Citrix or Terminal Services Webaccess - the program is installed independently and configured by editing text files manually, rather than through aGUI-based wizard. OpenVPN is not compatible with IPsec or any other VPN package. The entire package consistsof one binary for both client and server connections, an optional configuration file, and one or more key filesdepending on the authentication method used.

OpenVPN 58

Firmware implementationsOpenVPN has been integrated into routing firmware packages such as Vyatta, pfSense, DD-WRT,[18] OpenWrt andTomato,[19] allowing users to run OpenVPN in client or server mode from their network routers. A router runningOpenVPN in client mode, for example, facilitates users within that network to access their VPN without having toinstall OpenVPN on each computer on that network.

Firmware Package Cost Developer Link

DD-WRT Free NewMedia-NET GmbH dd-wrt.com [20]

IPFire Free Community driven development ipfire.org [21]

OpenWRT Free Community driven development OpenWRT.org [22]

PfSense Free BSD Perimeter LLC pfsense.org [23]

Tomato Free Keith Moyer tomatovpn.keithmoyer.com [24]

OpenVPN has also been implemented in some default manufacturer router firmware, such as the D-LinkDSR-250[25] and all recent MikroTik Routers.[26]

Community

A circa 2005 version of the OpenVPNcommunity logo.

There are many support options for OpenVPN. The primary method forcommunity support is through the OpenVPN mailing lists [27]. Othersources of support, not directly affiliated with OpenVPN include:

Support Source Description

OpenVPN Documentation 2.0 Manual [28] 2.1 Manual [29] 2.2 Manual [30] 2.3 Manual [31]

IRC #openvpn [32] on irc.freenode.net

Forum Official OpenVPN forums [33]

Community Official OpenVPN wiki/bug tracker [34]

OpenVPN e.V. community [35]

Secure Computing Networks OpenVPN Wiki [36]

OpenVPN 59

References[1] SourceForge.net - OpenVPN: openvpn-announce (http:/ / sourceforge. net/ mailarchive/ forum. php?max_rows=25& style=ultimate&

offset=25& forum_name=openvpn-announce)[2] http:/ / en. wikipedia. org/ w/ index. php?title=Template:Latest_stable_software_release/ OpenVPN& action=edit[3] ftp:/ / ftp. secure-computing. net/ pub/ openvpn[4] ftp:/ / ftp2. secure-computing. net/ pub/ openvpn[5] http:/ / en. wikipedia. org/ w/ index. php?title=Template:Latest_preview_software_release/ OpenVPN& action=edit[6] http:/ / openvpn. net/ index. php/ open-source. html[7] LinuxSecurity.com - OpenVPN: An Introduction and Interview with Founder, James Yonan (http:/ / www. linuxsecurity. com/ content/ view/

117363/ 49/ )[8] Network security hacks By Andrew Lockhart - Hack #104 - Create a Cross-platform VPN (http:/ / books. google. com/

books?id=6weH75ATpbUC& pg=PA339& dq=openvpn+ openssl& hl=en& ei=eJ16Tc2uNYXqOaepueoH& sa=X& oi=book_result&ct=result& resnum=1& ved=0CD4Q6AEwAA#v=onepage& q=openvpn openssl& f=false)

[9] IPv6 Deployment Guide By 6net - Chapter 5 - Integration and Transition (http:/ / books. google. com/ books?id=logdYuisKWgC&pg=PA109& dq=openvpn+ openssl& hl=en& ei=eJ16Tc2uNYXqOaepueoH& sa=X& oi=book_result& ct=result& resnum=2&ved=0CEMQ6AEwAQ#v=onepage& q=openvpn openssl& f=false)

[10] Overview of changes in OpenVPN v2.3 - ChangesInOpenvpn23 - OpenVPN Community (https:/ / community. openvpn. net/ openvpn/ wiki/ChangesInOpenvpn23)

[11][11] OpenVPN man page, section "TLS Mode Options"[12] http:/ / tools. ietf. org/ html/ rfc3948[13] User Centric Media: First International Conference, UCMedia 2009, Venice, Italy, December 9–11, 2009, Revised Selected Papers By

Patros Daras, Oscar Mayora Ibarra - Scalable IPTV Delivery to Home via VPN - Proposed Scheme (http:/ / books. google. com/books?id=ti8WoFmQHdoC& pg=PA239& dq=openvpn+ UDP& hl=en& ei=06F6TarwKoTvrAGGnLD9BQ& sa=X& oi=book_result&ct=result& resnum=10& ved=0CGQQ6AEwCQ#v=onepage& q=openvpn UDP& f=false)

[14] http:/ / www. opengroup. org/ onlinepubs/ 009695399/ functions/ mlockall. html[15] OpenVPN plug-in entry points for C based modules (http:/ / openvpn. git. sourceforge. net/ git/ gitweb. cgi?p=openvpn/ openvpn.

git;a=blob;f=openvpn-plugin. h;hb=HEAD#l30)[16] https:/ / community. openvpn. net/ openvpn/ wiki/ RelatedProjects[17] Nexus One Cyanogenmod changelog (http:/ / github. com/ cyanogen/ android_vendor_cyanogen/ blob/ eclair/ CHANGELOG)[18] dd-wrt.com - OpenVPN (http:/ / www. dd-wrt. com/ wiki/ index. php/ OpenVPN)[19] LinksysInfo.org – VPN build with Web GUI (http:/ / www. linksysinfo. org/ forums/ showthread. php?t=59416)[20] http:/ / www. dd-wrt. com/[21] http:/ / www. ipfire. org/[22] http:/ / www. openwrt. org/[23] http:/ / www. pfsense. org/[24] http:/ / tomatovpn. keithmoyer. com/[25] http:/ / www. dlink. com/ us/ en/ business-solutions/ security/ services-routers/ -/ media/ Business_Products/ DSR/ DSR%20250/ Manual/

DSR%20250_Manual_104_EN_US. pdf[26] http:/ / wiki. mikrotik. com/ wiki/ OpenVPN[27] http:/ / sourceforge. net/ mail/ ?group_id=48978[28] http:/ / openvpn. net/ index. php/ documentation/ manuals/ openvpn-20x-manpage. html[29] http:/ / openvpn. net/ index. php/ documentation/ manuals/ openvpn-21. html[30] http:/ / openvpn. net/ index. php/ open-source/ documentation/ manuals/ 427-openvpn-22. html[31] https:/ / community. openvpn. net/ openvpn/ wiki/ Openvpn23ManPage[32] irc:/ / irc. freenode. net/ openvpn[33] https:/ / forums. openvpn. net[34] https:/ / community. openvpn. net[35] http:/ / openvpn. eu[36] http:/ / www. secure-computing. net/ wiki/ index. php/ OpenVPN

OpenVPN 60

External links• OpenVPN project homepage (http:/ / openvpn. net/ index. php/ open-source. html)• OpenVPN presentation and demonstration video (http:/ / www. archive. org/ details/ HantsLUG_openvpn)

Hampshire Linux User Group. Archive.org. details (http:/ / www. hantslug. org. uk/ cgi-bin/ wiki. pl?TechTalks).

N2n 61

N2n

n2n

Developer(s) n2n team

Initial release March 27, 2008

Written in C

Operating system FreeBSD, Linux, OpenWrt, Mac OS X, Unix, Windows

Type VPN

License GNU General Public License

Website ntop.org/products/n2n [1]

n2n is an open source Layer 2 over Layer 3 VPN application which utilises a peer-to-peer architecture for networkmembership and routing.Unlike many other VPN programs, n2n can also connect computers which reside behind NAT routers. Theseconnections are set up with help from a third computer that both computers can reach. This computer, called asupernode, can then route the information between NATed nodes.[2]

It is free software licensed under the terms of the GNU General Public License v3.

Referenceshttp:/ / n2news. com[1] http:/ / www. ntop. org/ products/ n2n/[2] http:/ / www. ntop. org/ products/ n2n/ : "[the supernode] is basically a directory register and a packet router for those nodes that cannot talk

directly"

External links• n2n home page (http:/ / www. ntop. org/ products/ n2n/ )

Openswan 62

Openswan

Openswan

Stable release 2.6.38 / March 23, 2012

Preview release 2.6.39dr4 / April 29, 2013[1]

Operating system GNU/Linux , FreeBSD

Type IPsec

License GNU General Public License

Website openswan.org [2]

Openswan is a complete IPsec implementation for Linux 2.0, 2.2, 2.4 and 2.6 kernels.Openswan began as a fork of the now-defunct FreeS/WAN project, and continues to be released freely under theGNU General Public License. Unlike the FreeS/WAN project, it is not developed exclusively for the GNU/Linuxoperating system.

External links• Openswan website [2]

• Old Openswan wiki [3]

• Openswan bugtracker and new wiki [4]

References[1] https:/ / www. openswan. org/ news/ 12[2] http:/ / www. openswan. org/[3] http:/ / wiki. openswan. org/[4] http:/ / bugs. openswan. org/ projects/ openswan

StrongSwan 63

StrongSwan

strongSwan

Developer(s) Andreas Steffen, Martin Willi & Tobias Brunner

Stable release 5.0.4 / April 30, 2013

Operating system Linux, Android, Maemo, FreeBSD

Type IPsec

License GNU General Public License

Website http:/ / www. strongswan. org/

strongSwan is a complete IPsec implementation for Linux 2.6 and 3.x kernels. The focus of the project is on strongauthentication mechanisms using X.509 public key certificates and optional secure storage of private keys onsmartcards through a standardized PKCS#11 interface.

OverviewThe project is actively maintained by Andreas Steffen who is a professor for Security in Communications at theUniversity of Applied Sciences in Rapperswil, Switzerland.As a descendant of the FreeS/WAN project, strongSwan continues to be released under the GPL license. It supportscertificate revocation lists and the Online Certificate Status Protocol (OCSP). A unique feature is the use of X.509attribute certificates to implement access control schemes based on group memberships. StrongSwan interoperateswith other IPsec implementations, including various Microsoft Windows and Mac OS X VPN clients. The modularstrongSwan 5.0 branch fully implements the Internet Key Exchange (IKEv2) protocol defined by RFC 5996.

FeaturesStrongSwan supports IKEv1 and fully implements IKEv2.

IKEv1 and IKEv2 features•• strongSwan software is modular and offers dozens of plugins which enhance the functionality. The user can

choose among three crypto libraries (legacy [non-US] FreeS/WAN, OpenSSL, and gcrypt).•• Using the openssl plugin, strongSwan supports Elliptic Curve Cryptography (ECDH groups and ECDSA

certificates and signatures) both for IKEv2 and IKEv1, so that interoperability with Microsoft's Suite Bimplementation on Vista, Win 7, Server 2008, etc. is possible.

•• Automatic assignment of virtual IP addresses to VPN clients from one or several address pools using either theIKEv1 ModeConfig or IKEv2 Configuration payload. The pools are either volatile (i.e. RAM-based) or stored ina SQLite or MySQL database (with configurable lease-times).

• The ipsec pool command line utility allows the management of IP address pools and configuration attributes likeinternal DNS and NBNS servers.

StrongSwan 64

IKEv2 only features•• The IKEv2 daemon is inherently multi-threaded (16 threads by default). It has been shown that up to 20,000

concurrent IPsec tunnels can be handled on industry-grade VPN gateways.•• The IKEv2 daemon comes with a High-Availability option based on Cluster IP where currently a cluster of two

hosts does active load-sharing and each host can take over the ESP and IKEv2 states without rekeying if the otherhost fails.

•• The following EAP authentication methods are supported: AKA and SIM including the management of multiple[U]SIM cards, MD5, MSCHAPv2, GTC, TLS, TTLS. EAP-MSCHAPv2 authentication based on user passwordsand EAP-TLS with user certificates are interoperable with the Windows 7 Agile VPN Client.

•• The EAP-RADIUS plugin relays EAP packets to one or multiple AAA servers (e.g. FreeRADIUS or ActiveDirectory).

•• Support of RFC 5998 EAP-Only Authentication in conjunction with strong mutual authentication methods likee.g. EAP-TLS.

•• Support of RFC 4739 IKEv2 Multiple Authentication Exchanges.•• Support of the RFC 4555 Mobility and Multihoming Protocol (MOBIKE) which allows dynamic changes of the

IP address and/or network interface without IKEv2 rekeying. MOBIKE is also supported by the Windows 7 AgileVPN Client.

•• The strongSwan IKEv2 NetworkManager applet supports EAP, X.509 certificate and PKCS#11 smartcard basedauthentication. Assigned DNS servers are automatically installed and removed again in /etc/resolv.conf.

• Support of Trusted Network Connect (TNC). A strongSwan VPN client can act as a TNC client and a strongSwanVPN gateway as a Policy Enforcement Point (PEP) and optionally as a co-located TNC server. The followingTCG interfaces are supported: IF-IMC 1.2, IF-IMV 1.2, IF-PEP 1.1, IF-TNCCS 1.1, IF-TNCCS 2.0 (RFC 5793PB-TNC), IF-M 1.0 (RFC 5792 PA-TNC), and IF-MAP 2.0.

•• The IKEv2 daemon has been fully ported to the Android operating system including integration into the AndroidVPN applet. It has also been ported to the Maemo, FreeBSD and Mac OS X operating systems.

References

UML simulation environmentThe focus of the strongSwan project lies on the strong Authentication by means of X.509-Certificates, as well as theoptional safe storage of private key on smart cards with help of the standardized PKCS#11 interface, strongSwancertificate check lists and On-line Certificate Status Protocol (OCSP).An important capability is the use of X.509 Certificate Attributes, which permits it to realize complex access controlmechanisms on the basis of group memberships.strongSwan is however simple to configure and works smoothly with nearly all other IPsec implementations, inparticular also with various Microsoft Windows and Mac OS X-VPN-products.strongSwan comes with a simulation environment based on User-mode Linux. A network of eight virtual hostsallows the user to enact a multitude of site-to-site and roadwarrior VPN scenarios.

StrongSwan 65

External links• strongSwan website (http:/ / www. strongswan. org/ )• strongSwan with Trusted Network Connect (TNC) (http:/ / www. strongswan. org/ tnc/ )• strongSwan UML testing environment (http:/ / www. strongswan. org/ uml-testing. html)• LinuxTag 2008 Paper: strongSwan VPNs - modularized and scalable! (http:/ / www. strongswan. org/ docs/

LinuxTag2008-strongSwan. pdf)• LinuxTag 2007 Paper: strongSwan - the new IKEv2 VPN Solution (http:/ / www. strongswan. org/ docs/

LinuxTag2007-strongSwan. pdf)• LinuxTag 2005 Paper: Advanced Features of Linux strongSwan (http:/ / www. strongswan. org/ docs/

LinuxTag2005-strongSwan. pdf)• DFN 2005 Paper: Advanced Network Simulation under User-Mode Linux (http:/ / www. strongswan. org/ uml/

DFN_UML. pdf)

Tcpcrypt 66

Tcpcrypt

Original author(s) Andrea Bittau, Mike Hamburg, Mark Handley, David Mazières, Dan Boneh and Quinn Slack.

Type communication encryption protocol

Website tcpcrypt.org [1]

In computer networking, tcpcrypt is a transport layer communication encryption protocol. Unlike prior protocolslike TLS (SSL), tcpcrypt is implemented as a TCP extension. It was designed by a team of six security andnetworking experts: Andrea Bittau, Mike Hamburg, Mark Handley, David Mazières, Dan Boneh and Quinn Slack.Tcpcrypt has been published as an Internet Draft. Experimental user-space implementations are available for Linux,Mac OS X, FreeBSD and Windows. There is also a Linux kernel implementation.

DescriptionTcpcrypt provides opportunistic encryption — if either side does not support this extension, then the protocol fallsback to regular unencrypted TCP. Tcpcrypt also provides encryption to any application using TCP, even ones that donot know about encryption. This enables incremental and seamless deployment.Unlike TLS, tcpcrypt itself does not do any authentication, but passes a unique "session ID" down to the application;the application can then use this token for further authentication. This means that any authentication scheme can beused, including passwords or certificates. It also does a larger part of the public-key connection initiation on theclient side, to reduce load on servers and mitigate DoS attacks.

DisadvantagesTcpcrypt enforces TCP timestamps and adds its own TCP options to each data packet, amounting to 36 bytes perpacket. With a mean observed packet size for TCP packets of 471 bytes, this can lead to an overhead of 8% of usefulbandwidth. This 36 bytes overhead may not be an issue for internet connections faster than 64kbs, but can be anissue for dial up internet users.The current user space implementations are considered experimental and are reportedly unstable on some systems. Italso does not support IPv6 yet, which is currently only supported by the Linux kernel version. It is expected thatonce tcpcrypt becomes a standard, operating systems will come with tcpcrypt support built-in, making the user spacesolution unnecessary.

References[1] http:/ / tcpcrypt. org/

External links• tcpcrypt.org (http:/ / tcpcrypt. org/ )• Slides from USENIX 2010 presentation, explaining basics of tcpcrypt (http:/ / tcpcrypt. org/ tcpcrypt-slides. pdf)

Tinc (protocol) 67

Tinc (protocol)

Type self-routing, mesh networking protocol

License GPL

Website www.tinc-vpn.org [1]

Tinc is a self-routing, mesh networking protocol, used for compressed, encrypted, virtual private networks. It wasstarted in 1998 by Guus Sliepen, Ivo Timmermans, and Robert van der Meulen, and released as a GPL-licensedproject.

Supported network transports•• IPv4•• IPv6• Virtualized Ethernet (via TUN/TAP driver)

Embedded technologies• OpenSSL (encryption library)• zlib ("best compression")• LZO ("fast compression")

Projects that use tinc• Freifunk: tinc was enabled in their routers as of October 2006 [2].• OpenWrt has an installable package for tinc.• pfSense has a package in development for their 2.1 release [3]

External links• Homepage [1]

• Debian GNU/Linux tinc dhcp bridging setup [4]

• "Quick & Dirty TINC setup" [5]

• Gentoo Linux tinc setup [6]

References[1] http:/ / www. tinc-vpn. org/[2] http:/ / www. the-mesh. org/ tiki-read_article. php?articleId=39[3] http:/ / forum. pfsense. org/ index. php/ topic,53030. 15. html[4] http:/ / tinc-vpn. org/ examples/ simple-bridging-with-dhcp-server-side/[5] http:/ / www. vanheusden. com/ Linux/ tinc_mini_howto. html[6] http:/ / en. gentoo-wiki. com/ wiki/ Tinc

Cloudvpn 68

Cloudvpn

cloudvpn

Original author(s) Mirek Kratochvíl

Initial release December 2008

Stable release 1.99.8 / August 3, 2009

Platform Cross-platform

Type VPN

License GNU GPLv3

Website [ [1] ]

Cloudvpn is an open-source, mesh-networking capable communication tool. It differentiates itself from other VPNsby serving as a generic transport layer for any packet-based data traffic, which can include traditional VPN purpose,but is easily extensible to any other kind of traffic.

CapabilitiesCloudvpn tries to establish a decentralized transport network, routing through which is done using an optimizedDVR-like algorithm. This gives the "cloud" of nodes a great potential, allowing simple failover of connections andtraffic route optimalization.All transported traffic is encrypted, giving the peers some security against eavesdropping and related attacks.Communication peers, on the other side, aren't secured from attacks from themselves - one node can usually see andread all traffic coming through it, if the traffic isn't secured or encrypted on some higher level. Peers are thereforeneeded to trust each other.Cloudvpn is designed as a set of tools. Every node runs a 'cloud' program, which provides an encrypted connectionand mesh routing capabilities, and then attaches various other 'mesh clients', that communicate using the pre-creatednetwork. For example, 'ether' tool creates a virtual Ethernet interface and routes its traffic through the mesh, givingthe transport Ethernet-VPN capabilities. Other mesh clients are yet in development, WASTE-like features areplanned.

References[1] http:/ / freecode. com/ projects/ cloudvpn

Article Sources and Contributors 69

Article Sources and ContributorsVirtual private network  Source: http://en.wikipedia.org/w/index.php?oldid=576581260  Contributors: (, 1984, 2005, 2A01:E34:EEE1:48F0:E4D7:D2:ECE5:4166, 33rogers, A.amitkumar,ARTamb, Aaron north, Abune, Acole67, Adi4094, Aditya, Aeon17x, Agaffin, Alansohn, Aldie, AlewisGB, Alexamies, AlexeyN, Allstarecho, Alphawave, Alvestrand, Americaninseoul, Amux,AndreasJS, Andrew Gray, Andrewpmk, Angelbo, Anirvan, Anon lynx, Anthony Appleyard, AnthonyJ Lock, Apankrat, Apothecia, Armando, Art LaPella, Ashwin ambekar, Ausinha, Avaarga,Az1568, Azadk, Azerrima, Barek, Barek-public, Bbbone, Belmontian, Ben 9876, BenAveling, Bevo, Bewildebeast, BiT, Bigjust12345, BirdValiant, Bishopolis, Blacklogic, Blonkm, BlueJaeger,BlueNovember, Bmusician, Boardista, Bobo192, Borgx, Bovineone, Brainix, Brandon, Braviojk, Brwave, Bryan Derksen, Bswilson, C.Fred, CWenger, CYD, Can't sleep, clown will eat me,Carbuncle, Cfleisch, CharlotteWebb, Chealer, Chenghui, Chris Mounce, Chris the speller, Chris400, Chrisbolt, Chrisch, Chupacabras, Cleared as filed, ClementSeveillac, Cligra, Closedmouth,Cometstyles, Corinna128, Cpartsenidis, Cr0w, Crazytales, CutOffTies, Cwolfsheep, DBigXray, DKEdwards, Danno uk, David H Braun (1964), David Martland, David Woodward, Davidoff,Dbrodbeck, Decltype, Deeahbz, Deice, Deli nk, Delldot, DerHexer, Dewritech, Dgtsyb, Diablo-D3, Discospinster, Djg2006, Dmktg, Dmol, Doctorfluffy, Dpotter, DrFausty, Drable, DreamGuy,Drugonot, Dugnad, Długosz, E. Ripley, EagleOne, Edcolins, Edderso, Eenu, Efa, ElTopo, Eli77e, Elinruby, Emmatheartist, EncMstr, EoGuy, Epater, Epbr123, Escape Orbit, Eubene, EuroCarGT,Evansda, Everyking, Evice, Extraordinary, FAchi, FJPB, Falcon8765, Fancy steve, Fangfufu, Fieldday-sunday, Fijal, Fleminra, Flockmeal, Foggy Morning, Fosterbt, Foxb, Funnyfarmofdoom,Fuzheado, GL, GSK, Gadfium, Gardar Rurak, Gary King, Gascreed, Gaurav.khatri, GenOrl, Gershwinrb, Gilliam, Gkstyle, Glane23, Glenn, Godsmoke, Gracefool, Gracenotes, GraemeL, GroundZero, Gurdipsclick, Hadal, Haemo, Hal 2001, Happysailor, Harryzilber, Hcberkowitz, Hellisp, Heron, HisSpaceResearch, Humannetwork, Hyakugei, Ianmacm, Iceb, Ieopo, Informedbanker,Inkling, Intgr, Invenio, Ironman5247, Irulet, Isilanes, IvanStepaniuk, Izwalito, J'raxis, J.delanoy, JGXenite, JHunterJ, JNW, Ja 62, Jaan513, Jackcsk, Jackfork, Jadams76, Jags707, Jairo lopez,Jamesmcmahon0, Jandalhandler, Jasper Deng, Jazappi, Jcap1ln, Jdzarlino, Jemappelleungarcon, Jeremiah.l.burns, Jerome Charles Potts, JidGom, Jim.henderson, Jim1138, Jino123, Jlavepoze,Jleedev, Jmccormac, Jmundo, JoeSmack, John Vandenberg, John254, Johnuniq, Jojalozzo, JonHarder, Jonomacdrones, Joshk, Joy, Jrapo, Jrgetsin, Juliancolton, K-secure, Kaaveh Ahangar,Kamesg, Karlzt, Kateshortforbob, Katkay, Katkay1, Kbrose, Kevinzhouyan, Khag7, Kielvon, Kikbguy, Kilopi, Kimchi.sg, Kku, KnowledgeOfSelf, Kurt Jansson, Kuru, Kvng, L Kensington,LOL, Leafyplant, LeaveSleaves, LeedsKing, Les boys, LetMeLookItUp, Lightmouse, LindArlaud, LittleBenW, Lkstrand, Lmstearn, Lucaweb, Ludovic.ferre, Luna Santin, M. B., Jr., MCB,MER-C, MFNickster, Ma8thew, MainFrame, Majorly, Manop, MarcoTolo, Mashouri, Matt Crypto, MattTM, MattieTK, Maura Driscoll, Maxgrin, Me.rs, MeToo, Mebden, Mercury543210,Mercy11, Mfalaura, Mhking, Miabchdave, Michaelas10, Mike Rosoft, Mindmatrix, Ministry of Truth, Minna Sora no Shita, Mjs1991, Mkidson, Mmernex, Mohsen Basirat, Monkeyman,Movingonup, Mr.Clown, MrOllie, Mu Mind, Mxn, Naba san, Nacnud22032, Nardixsempre, Natalie Erin, Nealmcb, Negrulio, Neoalian, Netmotion1234, Niffweed17, Nkansahrexford, Nklatt,Noah Salzman, Nobletripe, Novastorm, Nqtrung, Ntsimp, Nubiatech, Nuno Tavares, Nurg, Nuttycoconut, Octahedron80, Ohconfucius, Oli Filth, Omicronpersei8, Optimist on the run,Ottawa4ever, OverlordQ, Pascalv, Paulehoffman, Pauli133, Pdcook, Pearle, Peteinterpol, Peter M Dodge, Phatom87, Philomathoholic, Phr, Pinchomic, Pinethicket, Plat'Home, Plyd, Pmcm, Pnm,Pokrajac, PositiveNetworks, Prakash Nadkarni, Prari, ProfPolySci45, PuerExMachina, Quarl, R'n'B, R. S. Shaw, R00stare, RFightmaster, RHaworth, RM MARTIN, Raanoo, Rafigordon,RainbowOfLight, Raprap321, Rashoba, Ray Dassen, RayAYang, Razorflame, Rearden9, RedHillian, Redlazer, Rees11, Regancy42, Reliablehosting, Res2216firestar, Rgore, Rhobite, Rich45,Rjwilmsi, Rninneman, Robert Brockway, Rocketron5, Rosothefox, SPat, START-newsgroup, Saimhe, Sajjad36122061, Scarpy, Schecky4, Scott.somohano, SecurityManager, Selah28,Sepersann, Sgarson, Shadowjams, Shandon, ShelleyAdams, Shierro, Shijiree88, ShorelineWA, Sijokjose, SilentAshes, Sintesia, Skarebo, Skier Dude, Skizzik, Smallman12q, SmartGuy Old,Smartchain, Smithkkj, Snaxe920, Snow Blizzard, Snowolf, SpaceFlight89, SqueakBox, Stdundon, Stephenb, Strike Eagle, Student geek, Sujathasubhash, Sunny2who, Superpixelpro, Swartik,Sydbarrett74, Szquirrel, THEN WHO WAS PHONE?, Tahren B, Talinus, TastyPoutine, Tech editor007, TechyOne, TehPhil, Teknetz, Thane, Thatguyflint, Thaurisil, The Anome, The ThingThat Should Not Be, TheBilly, TheNeutroniumAlchemist, ThePromenader, Therefore, Thumperward, Tide rolls, Timurx, Tlroche, Tobias Bergemann, Tom Foley, Tomlee1968, Tommy2010,TonyUK, Torqueing, Trailbum, Tryggvia, Tslocum, Tuxa, Tuxcrafter, TwoTwoHello, Unixer, Utcursch, VPN.PRO, Vanderdecken, Vanisheduser12345, Veinor, Vicarious, Vickey2020,Visiting1, Vjardin, Vladkornea, W.F.Galway, WEJohnston, Wackywace, WakingLili, WarrenA, Wavelength, WebHamster, Webster21, Webwat, Whaa?, Widefox, Widr, Wik, Wiki 101,Wikievil666, Wikingtubby, Williameboley, Wimt, Winchelsea, Winterst, Wknight94, Wodkreso, Woohookitty, Ww, Xenomm, Xpclient, YUL89YYZ, Yama, Yamamoto Ichiro,YordanGeorgiev, Youssefsan, Ywalker79, ZeroOne, Zeroshell, Ziabhat, Zzuuzz, Тиверополник, 1420 anonymous edits

Secure Socket Tunneling Protocol  Source: http://en.wikipedia.org/w/index.php?oldid=563954558  Contributors: Brandon, Enaess, Garlicblub, Idduka, Javawizard, Jformacek, Jojalozzo,JosephDavies, Knurmia, Larzi, Laslovarga, LilHelpa, Lopifalko, Normis99, Phatom87, Pmsyyz, R'n'B, RVAMiles, Rurik, Sobreira, Susiemorgan, Uebayasi, Xpclient, Yustein, 37 anonymousedits

IPsec  Source: http://en.wikipedia.org/w/index.php?oldid=574772095  Contributors: (, 00110001, 2001:5C0:1000:A:8000:0:ADA9:BDBF, 2600:3C03:0:0:F03C:91FF:FE93:2A8A,28421u2232nfenfcenc, AShadowed, AVand, Aaronbrick, Abdull, Abune, Aldie, AlephGamma, Alvestrand, Anon lynx, Ashdurbat, Asteffen, B, Barek, Beland, BenAveling, Bender235, Betbest1,Borgx, Breno, Brian Patrie, Bryan Derksen, BurritoBazooka, Bushhopper, Can't sleep, clown will eat me, Captain panda, Cburnett, CesarB, Cfleisch, Cheungpat, Chuq, Cnadig, Cokoli,Comatose51, CommonsDelinker, Cpartsenidis, Crakkpot, Cschlatt, Cwolfsheep, CyberSkull, Cybercobra, Cybjit, DGtlRift, Dandorid, DataWraith, Daveg1k, Davidvandebunte, Dbrodbeck,Dcirovic, DomQ, Drangon, Dugauthier, Ebikeguy, ElKevbo, Elimerl, Elriond-1, Elsendero, Enjoi4586, EnzoMatrix, Falcon9x5, Falconsgladiator, Flockmeal, Flyer 13, Fornn50386503, Fragglet,Frap, Fylke, Gadget850, Giftlite, Grahame, Greengreengreenred, Gudeldar, Haakon, Hairy Dude, Harishpillay, Hawaiian717, Hede2000, Herbertxu, Het, Hmwith, Htrstc, Hu12, Huitema,Huygens 25, I dream of horses, Ilia Kr., Int21h, Intgr, Isilanes, J.delanoy, Jandalhandler, Janizary, Jdeg, Jearle, Jedikaiti, Jengelh, Jerimiah McCain, JidGom, Johnuniq, Jonathanbenari, Jtdowney,Karn, Kbrose, Ken g6, KenBailey, KentTong, Ketiltrout, Kgfleischmann, Khazar2, Kimvais, Kinema, Ksylian, Kwiki, Liberty Miller, LilHelpa, Limbo socrates, Lxr1234, M. B., Jr., Mahdeto,Mange01, Marek69, MarioS, Markaci, Materialscientist, Mator, Matt Crypto, Mbaer3000, Mcr314, Me and, Mecki78, Menkalos, Mike Rosoft, Mindmatrix, Minesweeper, Mintleaf, MitRouting,Mitch Ames, Mmernex, Mout, MrOllie, MusikAnimal, Nabber00, NapoliRoma, Nate Silva, Ncbhavsar, Nealmcb, Neillucas, Niceguyedc, Nichtich, Nick Number, Nicolas Barbier, Nikicat,Niteowlneils, Novasource, Ntsimp, Pabouk, Paul Koning, Paulehoffman, Phatom87, Philmonty, Plat'Home, Plustgarten, Pol098, Postrach, Pwouters, Quanstro, Racaille, Rafigordon, Rchandra,Rearden9, RedWolf, RexNL, Reza 2638, Rich257, Rjsrjs, Rjwilmsi, RossPatterson, Royhills, Rsrikanth05, Samikamel, Scott.somohano, Senator2029, Sietse Snel, Soltwisch, SouthLake,SpaceFlight89, Spearhead, Srinikal, Stan Shebs, Stdundon, Stephan Leeds, Storkk, Subrata23, Sunny256, Suruena, THF, Taral, Tech editor007, Thane Eichenauer, The Anome, TheProject, Thue,Tje, TonyW, Victor, Vil, Vjardin, Vtomic85, Wellithy, Whitepaw, Whkoh, Wiki alf, Wikieditor06, Wilcho, WillDeed, Wilson.canadian, Winterst, Wmahan, Writermonique, Ww, Xpclient,YUL89YYZ, Yachtsman1, Yaronf, Ykanada, Ynhockey, Zareous, Zoicon5, 500 anonymous edits

Layer 2 Tunneling Protocol  Source: http://en.wikipedia.org/w/index.php?oldid=575853030  Contributors: A5b, Aaronbrick, Andareed, Anon lynx, Apyule, AxelBoldt, Borgx, CaptainConundrum, CecilWard, ChrisGualtieri, CiaPan, Cibu, Cryptic, Cwolfsheep, Daedalus01, Dispenser, Dmeranda, Enjoi4586, Evil saltine, Ferdinand Pienaar, Fontoponto, Free49498445,Frencheigh, Gogo Dodo, Hom sepanta, IlyaHaykinson, Infofarmer, JHunterJ, JTN, Jerimiah McCain, John Cardinal, K3rb, Kbrose, Kinema, Krankes-kind, LittleWink, Matieux, Mdmkolbe,Mendaliv, Metaclassing, Mmtmmt, Moocha, MrJones, MrOllie, Muhandes, Muruga86, Mwaisberg, Nate Silva, Nealc, NescioNomen, Oblivious, Ohnoitsjamie, Peyre, Plat'Home, Rednectar.chris,Sietse Snel, Skeffling, Some standardized rigour, Spearhead, Srbauer, Stephan Leeds, TechyOne, The Anome, TheAnarcat, Unyoyega, Vjardin, W Nowicki, Walkerhamilton, Web-CrawlingStickler, Wrs1864, Xauen, Xpclient, Yaronf, Ylem, Ynhockey, ^demon, 132 anonymous edits

L2TPv3  Source: http://en.wikipedia.org/w/index.php?oldid=572465648  Contributors: Bear1952, Bevo, CatherineMunro, Cburnett, Cwolfsheep, Danhash, JTN, Jchapman0, Jim.henderson,Niteowlneils, Plat'Home, Quota, Srbauer, Theroachman, Wolfgang42, 22 anonymous edits

Point-to-Point Tunneling Protocol  Source: http://en.wikipedia.org/w/index.php?oldid=574324433  Contributors: (, .:Ajvol:., A Meteorite, A5b, Adavidb, Albertelmore, Andareed, Anon lynx,Ark30inf, Arunsingh16, Audin, AxelBoldt, Bbb2007, Bevo, Binnacle, Bryan Derksen, CesarB, Chèvredansante, Comzone, Cwolfsheep, DStoykov, Dajhorn, Daniele.tampieri, Desummoner, Etu,Fancy steve, Hverbiesen, Hyfen, Ian Macintosh, Imcon, JHunterJ, Janizary, Joh6nn, Jrkarp, Kat.b.gilley, Kbrose, Kjetil r, Kotra, Kuru, Kvng, Langus-TxT, Marvelscience, MathsPoetry, MattCrypto, Mercury543210, Mindmatrix, Moosebutter, MrOllie, Nealmcb, Noloader, Novasource, Peyre, Phatom87, Plat'Home, Pomakis, Radialink, Rashob, Rchandra, RedWolf, Reedy, RobertBrockway, Scaredpoet, Securiger, Sfiller, SickTwist, Snori, Sparc317, Spearhead, Ta bu shi da yu, The Anome, Tide rolls, TrygveFlathen, Vanished user kjdioejh329io3rksdkj, Weialawaga,Widefox, Wmauer, Wrs1864, Xauen, ZKaiser, ZeroOne, 137 anonymous edits

Split tunneling  Source: http://en.wikipedia.org/w/index.php?oldid=573164620  Contributors: Bswilson, Cwolfsheep, Danlev, Download, Hu12, Jesser07, Lensovet, Mauricev, Miqrogroove,Mpmartin8080, Phatom87, Raistolo, Sh00tr, Svick, 18 anonymous edits

Transport Layer Security  Source: http://en.wikipedia.org/w/index.php?oldid=576627891  Contributors: 08af9a09, 0x6adb015, 2601:0:B780:1DB:14B7:F6C4:C86C:76F, 2620:0:1000:2B01:B5D6:E175:39A3:D895, 5ko, 806f0F, Abaybas, Abdull, AbsolutDan, Acodring, Adam Conover, Adrianfd, Aethedor, Aka042, Akebinho, Alansohn, Albedo, Aldie, Alec it, Alias Flood, AlistairMcMillan, Alphathon, Amenel, Anclation, Andre Engels, Andrei.wap, Andrew Hampe, Andrzej P. Wozniak, Anna512, Anon lynx, Ant honey, Antientropic, Apankrat, Aprock, Aprogrammer, Arkoon, Arman Cagle, Armour Hotdog, Arronax50, Arsenikk, Ashdurbat, Avbentem, AxelBoldt, Barakw, Barek, Beetstra, Beland, Bender235, Beno1000, Biot, Bklisch, Blackbearded, BlindWanderer, Blodulv, Boblord, Boomboombi, Borb, Bovineone, Branko, Branlon, Breno, Bryan Derksen, Btrzupek, Bugorsky, Bunnyhop11, Burke Libbey, Bxj, C1010, CKlunck, Cajunbill, Calton, CanadianLinuxUser, CanisRufus, Cellmate707, Cf. Hay, Cfp, Chaliy, Chealer, Chester Markel, Chris conlon, Ciphers, ClementSeveillac, Codelux, Colenso, Colonies Chris, Comet Tuttle, CommonsDelinker, Complicated1, Conseguenza, Conversion script, Crossland, Czhower, DARTH SIDIOUS 2, Daira Hopwood, Damian Yerrick, Daniel.Cardenas, Davidfstr, Davidoff, Davodd, Dawnseeker2000, Deadbeef, Debresser, Deedub1983, Devon Sean McCullough, Dfarrell07, Dictouray, Digi-cs, Discospinster, Diyoev, Doedoejohn, Dogbyter, Dougjih, DouglasCalvert, Dreamafter, Ed Brey, Edward, Elvey, Emperorbma, Enjoi4586, Ercrt, Ericnay, Erth64net, Eruionnyron, Esmond.pitt, Etu, Everyking, Evice, ExportRadical, Eyreland, FBarber, Faizan, Falcon8765, Feezo, Felixcatuk, FireballDWF2, FlippyFlink, FloydRTurbo, Frap, Fresheneesz, Freyr, Fritzophrenic, Fryed-peach, Furrykef, Fylbecatulous, GABaker, Gareth Griffith-Jones, Gerbrant, Ghalas, Ghettoblaster, Gidoca, Giftlite, Ginsuloft, Gionnico, GoodStuff, Gracefool, Graham87, Greatwhitesharkbear, GreyCat, Groovy12, Guthrg007, Guy Macon, Gzorg, Haakon, HaeB, Haham hanuka, Hairy Dude, HamburgerRadio, Hanche, Hawk-Eagle, Hgfernan, Hottdee, I dream of horses, Iangfc, Ianmacm, Iida-yosiaki, Imroy, Int21h, Interiot, Intgr, Isilanes, Itahmed, J-p krelli, JTN, JWilk, JaGa, Jamelan, Jandalhandler, Jas4711, Jc monk, Jclemens, Jcsouthworth, Jdthood, Jef-Infojef, Jesant13, Jesse Viviano, Jigen III, Jjplaya209, Jlehen,

Article Sources and Contributors 70

Jmaister, Jmorgan, JoanneB, JoaoRicardo, Joblack, JonHarder, Jpinkerton88, Juhovh, Julie Deanna, Kbrose, Kelson, Kgaughan, Kgfleischmann, Kinema, Koektrommel, Koeplinger, Kpsmithuk,Kravietz, Krellis, Ksn, Kyng, Lakshmin, LeoNomis, Leotohill, Levin, LittleBenW, Loftenter, Lopifalko, Lotje, Lradrama, Lukegilman, Lundse, Lunkwill, Lzyiii, M. B., Jr., Maartenvanrooijen,Mabdul, Mac, Madigral, MadmanNova, Magioladitis, MagnetiK, MajorVariola, Makerofthings7, Mange01, Mani1, Marrowmonkey, Martijn Hoekstra, Martinkunev, Materialscientist, MattCrypto, Matthew V Ball, Maxim Razin, Mayevski, Meetabu, Meowimasexycat, Mgcsinc, Michael Hardy, MichaelCoates, Michaelfowler, Michaelkrauklis, Mickraus, Mike Rosoft, Mild BillHiccup, Mindmatrix, MinorContributor, Mischling, MisterSSL, Mjb, Mmernex, Mogism, Molf, Moocha, Morning Sunshine, Mpvdm, Mr Heine, MrOllie, Mrbbking, Msiddalingaiah, Mundocani,Mwanner, Mydogategodshat, Mårten Berglund, N.MacInnes, Nagle, Nahiyan8, Nealcardwell, Nealmcb, Nerwal, Nikai, Nill smith, Nils, Ninels, Niqueco, Nitrogenx, Nk, Nmav, Noloader,Nonno88, Noq, Ntsimp, Nubiatech, Nurg, Nuujinn, Nyco, ObscurO, Oconnor663, Olegos, Olivier Debre, Omniplex, Oscardt, OwenBlacker, PHansen, Palmbeachguy, Papadopa, Pasi Eronen,Paul Foxworthy, Paul1337, PeterB, Pfortuny, Phoenix-forgotten, PieterDeBruijn, Pilotguy, Pizzamancer, Plugwash, Plustgarten, Pmsyyz, Ppelleti, Produke, Psz, Qslack, QuiteUnusual, RP459,Raanoo, Rafigordon, Raghith, Rarut, Rasmus Faber, Raviaulakh, Ray Dassen, Remember the dot, Rettetast, ReyBrujo, Rholton, Rhomboid, Rich Farmbrough, RichiH, Rick Block, Ripsss,Rlcantwell, Robertssh, Robinalden, Robvanvee, Ross Fraser, Rushyo, SCΛRECROW, SPCartman, SSLcertificatesecurity, Sachuraju, Sanxiyn, Sara Wright, Sbose7890, Scetoaux, Schlafly,Schmalls, Seneces, Sesu Prime, Shaddack, Shadowjams, Shaggyjacobs, ShakataGaNai, Siddhant, Simetrical, Simon.may.007, Sjö, Skizzik, Sleske, Smyth, SoledadKabocha, Spartan-James,Speaker to Lampposts, SpeedyGonsales, Star General, Startcom, Stefonic, Stephan Leeds, Strebe, Stupid Corn, Sun Creator, Super48paul, Superm401, Suruena, Swagatata, Sweeper tamonten,TDM, THEN WHO WAS PHONE?, TJJFV, Ta bu shi da yu, Tacke, Tbhotch, Tbutzon, Tcc8, Ternto333, The Anome, TheWishy, Themfromspace, Thomas Springer, Thomasgud, Thompor,Thorne, Thulasi.goriparthi, Thumperward, Thunderbritches, ThurnerRupert, Tijfo098, Tim Ivorson, Timberframe, Titiri, Tommy2010, Tony esopi patra, Toyotabedzrock, Tpbradbury, Tqbf,Tracef2112, Trailspark, Traveler100, TwelveBaud, Twkd, Typhoonhurricane, UncleBubba, Unixman83, Uogl, Usaguruman, VAcharon, Vanished user kjdioejh329io3rksdkj, Verdy p, Versageek,VictorAnyakin, Vijay.kotari, Vinayr rao, VishalJBhatt, WLU, Wavelength, Wdspann, Webguynik, Weedwhacker128, Weyes, Wiarthurhu, Widefox, Wikisuzan, Wikivhz, Wilfrednilsen, WillFaught, William Avery, WinTakeAll, Winterst, Wizofaus, Wmahan, Wmasterj, WojPob, Writermonique, Wutherings, Ww, Xizhi.zhu, Yadirh, Yaronf, Yellow Lilt, Yonatan.graber,Youremyjuliet, Ysimonson, Yuhong, Zigkill, Zimbabweed, Zr40, Zundark, Zwodrei, Zzuuzz, 책읽는달팽, 968 anonymous edits

Social VPN  Source: http://en.wikipedia.org/w/index.php?oldid=572486444  Contributors: Aavindraa, Abi79, Amalthea, Behnam, Cwolfsheep, Frap, Gummismari, Haakon, John of Reading,Jojalozzo, Kevinzhouyan, Lesser Cartographies, MBisanz, Mdd, MuZemike, Ptony82, Renatofig, Scarpy, 18 anonymous edits

OpenVPN  Source: http://en.wikipedia.org/w/index.php?oldid=576580466  Contributors: 2001:470:50F9:1:3C57:505A:71F2:9237, 2001:7C0:705:1:0:0:0:4,2A01:E34:EEE1:48F0:E4D7:D2:ECE5:4166, Aavindraa, AbderrahmanNajjar, Ahunt, Alainamedeus, Albertalbs, AlistairMcMillan, Alonbl, Alvin-cs, AndrewHowse, Andreystrelkov,AndyLim091, Antonielly, Apyule, Archer3, Barek, Bender235, Bensin, Bevo, Binarypower, Boobarkee, Boris Friedrichs, Bryan Derksen, Carpetsmoker, ChrisGualtieri, Christophocles, Cintema,Cntras, Coj, CommonsDelinker, Crucis, Cvandeplas, Cwolfsheep, Daderot, Dautranhsinhton, Deedsnance, Deli nk, Disdero, Ecrist, Efa, Ehn, Elektron, EncMstr, Enviroboy, Epater, EugeneKay,Family Guy Guy, Fleminra, Fmusinguzi, Frap, Garing, Ggeller, Ghen, Glenn, GraemeL, GuizmOVPN, GutoCarvalho, Guyjohnston, Götz, Imcon, Innv, Inter, Intgr, Irulet, Isilanes, Ivankb,JamesAM, Jamesyonan, Jasper Deng, Jbekkema, Jdthood, Jmnbatista, JonHarder, Jonik, Joseluisfb, Justin Ormont, Karn, Karnesky, Karthik.upadhyayula, Kbrose, Kevinzhouyan, Kikbguy,Klisanor, Kristian.luck, KyjL, LX, Leotohill, Lexein, LiX, Lopifalko, MMuzammils, MaTT, Magioladitis, MartinMichlmayr, Marycontrary, Matt Crypto, Mattman00000, Mindmatrix,Mlpotgieter, Mr700, MrOllie, NapoliRoma, Nmav, Nubiatech, PabloCastellano, Pagingmrherman, PersistentLurker, Phatom87, Plaisthos, Plat'Home, PlatinumX, Pmsyyz, Poppafuze, Rafesq,Rancher 42, Rashob, Rashoba, Rjgodoy, Robertducon, RoySmith, SURIV, Sabroadley, Same0ff, Scarpy, Schapel, Seaphoto, Shaddack, Shanes, Sietse Snel, Smeago, Smokris, Stephan Leeds,Teratornis, TheBilly, Thelle, Thumperward, TiagoPereira, Tobmaster1985, Tsepty, Wikingtubby, Wilhelmina clemenso, Wlindley, Wzyboy, Xauen, ZoeB, 237 anonymous edits

N2n  Source: http://en.wikipedia.org/w/index.php?oldid=568729394  Contributors: Aavindraa, Alaric, AlexandrDmitri, AzertyFab, Cwolfsheep, DTOx, Frap, Gu1dry, JLaTondre, Justin Ormont,K5okc, Muhandes, Od Mishehu, Overand, Rancher 42, Rich Farmbrough, Tange, Wkussmaul, 14 anonymous edits

Openswan  Source: http://en.wikipedia.org/w/index.php?oldid=556618016  Contributors: AXRL, Aavindraa, Arite, CommonsDelinker, Cwolfsheep, Edward, Etrillaud, Frap, Isilanes, Joy,Katherine Shaw, Kl4m-AWB, Mabdul, Mcr314, Mr flea, Nimhs, Plat'Home, Sleepyhead81, Sn0wflake, Speck-Made, Tianjiao, Toxiczka, Uzytkownik, Wisq, Xmteam, 22 anonymous edits

StrongSwan  Source: http://en.wikipedia.org/w/index.php?oldid=552855681  Contributors: 2A01:E34:EEE1:48F0:E4D7:D2:ECE5:4166, Aavindraa, Asteffen, CommonsDelinker, David Gerard,Dawynn, Fast healthy fish, Frap, Geniac, Gurdipsclick, Hwithaar, Isilanes, Jasper Deng, Jojalozzo, K3lw3ll, Kenb215, Kl4m-AWB, Nimhs, Roland zh, Royhills, Thequux, 21 anonymous edits

Tcpcrypt  Source: http://en.wikipedia.org/w/index.php?oldid=574358371  Contributors: Anceurs, Chris Chittleborough, Debresser, Dominus, Eyreland, Fzz85, Intgr, Jec, John of Reading,Jonathan Williams, Kingturtle, Mhandley, Nyttend, RHaworth, Tabletop, Widefox, 5 anonymous edits

Tinc (protocol)  Source: http://en.wikipedia.org/w/index.php?oldid=535275944  Contributors: 1010S1011, Cwolfsheep, Nipsonanomhmata, Tabletop, Tuxcrafter, 10 anonymous edits

Cloudvpn  Source: http://en.wikipedia.org/w/index.php?oldid=575811817  Contributors: Aavindraa, ArcAngel, Btilm, Glenn, Katenoox, Tikiwont, 8 anonymous edits

Image Sources, Licenses and Contributors 71

Image Sources, Licenses and ContributorsFile:Virtual Private Network overview.svg  Source: http://en.wikipedia.org/w/index.php?title=File:Virtual_Private_Network_overview.svg  License: Creative Commons Attribution-Share Alike Contributors: Ludovic.ferreImage:l2tp pkt exchg.PNG  Source: http://en.wikipedia.org/w/index.php?title=File:L2tp_pkt_exchg.PNG  License: Public Domain  Contributors: A3 nm, Muruga86File:Ovpntech logo-s REVISED.png  Source: http://en.wikipedia.org/w/index.php?title=File:Ovpntech_logo-s_REVISED.png  License: Creative Commons Attribution-Sharealike 3.0 Contributors: OpenVPN Technologies, Inc.File:OpenVPN logo whirl.jpg  Source: http://en.wikipedia.org/w/index.php?title=File:OpenVPN_logo_whirl.jpg  License: GNU Free Documentation License  Contributors: User:MarycontraryImage:StrongSwan UML topology.png  Source: http://en.wikipedia.org/w/index.php?title=File:StrongSwan_UML_topology.png  License: GNU Free Documentation License  Contributors:Asteffen, Zeimusu

License 72

LicenseCreative Commons Attribution-Share Alike 3.0//creativecommons.org/licenses/by-sa/3.0/