Point-to-Point Tunneling Protocol PPTP

The Point-to-Point Tunneling Protocol (PPTP) is a method for implementing virtual private networks. PPTP uses a 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 PPP protocol being tunneled to implement security functionality. However the most common PPTP implementation, shipping with the Microsoft Windows product families, implements various levels of authentication and encryption natively as standard features of the Windows PPTP stack. The intended use of this protocol is to provide similar levels of security and remote access as typical VPN products.

Specification

A specification for PPTP was published as RFC 2637[1] and was developed by a vendor consortium formed by Microsoft, Ascend Communications (today part of Alcatel-Lucent), 3Com, and others. PPTP has not been proposed 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 to initiate 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 typical routing field in the GRE header. However, like in a normal GRE connection, those modified GRE packets are directly encapsulated 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 be carried within PPP, including IP, NetBEUI and IPX.

In the Microsoft implementation, the tunneled PPP traffic can be authenticated with PAP, CHAP, MS-CHAP v1/v2 or EAP-TLS. The PPP payload is encrypted using Microsoft Point-to-Point Encryption (MPPE) when using MS-CHAPv1/v2 or EAP-TLS. MPPE is described by RFC 3078

Implementations

PPTP was the first VPN protocol that was supported by Microsoft Dial-up Networking. All releases of Microsoft Windows since Windows 95 OSR2 are bundled with a PPTP client, although they are limited to only 2 concurrent outbound connections. Microsoft Windows Mobile 2003 and higher also support the PPTP protocol. The Routing and Remote Access Service for Microsoft Windows contains a PPTP server. The Microsoft implementation uses single 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 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. The first PPTP implementation was developed by Matthew Ramsay in 1999. and initially distributed under the GNU GPL by Moreton Bay. However, Linux distributions initially lacked full PPTP support because MPPE was believed to be patent 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 also ACCEL-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 OS releases. Palm PDA devices with Wi-Fi are bundled with the Mergic PPTP client.[citation needed]

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

Security

PPTP has been the subject of many security analyses and serious security vulnerabilities have been found in the protocol. The known vulnerabilities relate to the underlying PPP authentication protocols used, the design of the MPPE protocol as well as the integration between MPPE and PPP authentication for session key establishment.

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.
    When using MSCHAP-v1, MPPE uses the same RC4 session key for encryption in both directions of the communication flow. This can be cryptanalysed with standard methods by XORing the streams from each direction together.
    MSCHAP-v2 is vulnerable to dictionary attack on the captured challenge response packets. Tools exist to perform this process rapidly.
    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 and therefore the ciphertext is vulnerable to a bit-flipping attack. An attacker could modify the stream in transit and adjust single bits to change the output stream without possibility of detection. These bit flips may be detected by the protocols themselves through checksums or other means.

EAP-TLS is seen as the superior authentication choice for PPTP;  however, it requires implementation of a Public Key Infrastructure for both client and server certificates. As such it is not a viable authentication option for many remote access installations.

Secure Socket Tunneling Protocol SSTP

Secure Socket Tunneling Protocol (SSTP) is a form of VPN tunnel that provides a mechanism to transport PPP or L2TP traffic through an SSL 3.0 channel. SSL provides transport-level security with key-negotiation, encryption and traffic integrity checking. The use of SSL over TCP port 443 allows SSTP to pass through virtually all firewalls and proxy servers.

SSTP servers must be authenticated during the SSL phase. SSTP clients can optionally be authenticated during the SSL phase, and must be authenticated in the PPP phase. The use of PPP allows support for common authentication methods, such as EAP-TLS and MS-CHAP.

SSTP is available for Linux, Mac OS, BSD and Windows.

For Windows, SSTP is only available since version Windows Vista SP1, in RouterOS, and in SEIL since its firmware version 3.50. It is fully integrated with the RRAS architecture in these operating systems, allowing its use with Winlogon or smart card authentication, remote access policies and the Windows VPN client.

SSTP is only for remote client access, it does not support site-to-site VPN tunnels.

SSTP suffers from the same performance limitations as any other IP-over-TCP tunnel. In general, performance will be acceptable only as long as there is sufficient excess bandwidth on the un-tunneled network link to guarantee that the tunneled TCP timers do not expire. If this becomes untrue, performance falls off dramatically. This is known as the "TCP meltdown problem

L2TP/IPsec

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

        Negotiation of IPsec security association (SA), typically through Internet key exchange (IKE). This is carried out over UDP port 500, and commonly uses either a shared password (so-called "pre-shared keys"), public keys, or X.509 certificates on both ends, although other keying methods exist.
        Establishment of Encapsulating Security Payload (ESP) communication in transport mode. The IP protocol number 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.
        Negotiation and establishment of L2TP tunnel between the SA endpoints. The actual negotiation of parameters takes 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 L2TP packet itself is wrapped and hidden within the IPsec packet, no information about the internal private network can be garnered from the encrypted packet. Also, it is not necessary to open UDP port 1701 on firewalls between the endpoints, since the inner packets are not acted upon until after IPsec data has been decrypted and stripped, which 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 tunnel refers to a channel which allows untouched packets of one network to be transported over another network. In the case of L2TP/PPP, it allows L2TP/PPP packets to be transported over IP. A secure channel refers to a connection within which the confidentiality of all data is guaranteed. In L2TP/IPsec, first IPsec provides a secure channel, then L2TP provides a tunnel.