Point-to-Point Tunneling Protocol (PPTP) is a protocol layer on top of the PPP protocol that allows the secure "tunneling" of encrypted data between any computers attached to a TCP/IP network. Using PPTP, you can create a virtual private network (VPN) over public networks.

PPTP simulates NDIS LAN adapters that provide an encrypted bi-directional data stream channel to the TCP/IP computers on each end of the connection.

PPTP in its barest form works by encapsulating virtual private network packets inside of PPP packets, which are then encapsulated in Generic Routing Encapsulation (GRE) packets sent over IP to the destination PPP server and back again. There is also a TCP-based control session used to query status and signaling information between both ends of the PPTP link. The IETF draft by Hamzeh, et. al. that describes this protocol does not specify any specific algorithms or protocols to be used for authentication or encryption, instead specifying a means by which these parameters can be negotiated between the peers connecting. These negotiations are based on the existing methods dialup lines using PPP negotiate compression and other parameters. This flexibility has allowed the extremely weak PPTP implementation by Microsoft.

Bruce Schneier and Mudge of L0pht attacked Microsoft's particular implementation of this protocol for Windows NT and found that it was embarrasingly insecure. The authentication protocol is truly weak, relying on the security of user-remembered passwords (and we all know how good THOSE tend to be!). What makes this worse is that they used a very weak hash function that was first developed for LAN Manager. The protocol only authenticated clients, so it was susceptible to man in the middle attacks by someone impersonating the server by hijacking a connection. The Microsoft Point-to-point Encryption (MPPE) protocol also generated the encryption keys for a perfectly good cipher (RC4) by using, once again, the user's passwords, making the security of the encryption no greater than the security of the password. They also violated one of the cardinal rules for using stream ciphers like RC4 which anyone who ever bothered to read Applied Cryptography would know: never use the same key twice. For 40-bit encryption the same key was used all of the time, for 128-bit encryption the same key was used to encrypt data in both directions. Reusing the key for an OFB-mode stream cipher like RC4 has the same effect as reusing the key for a one time pad: someone can then trivially XOR two ciphertext streams together and recover the keystream!

After the furor surrounding the publishing of these devastating cryptanalytic results, Microsoft came up with a new version of the protocol that attempted to address the weaknesses uncovered by Schneier and Mudge. The two then proceeded to look for other problems in the new protocol. While most of the weaknesses they uncovered in the first version have been somewhat effectively fixed, one of the main problems--that the keys used are ultimately derived from user-supplied passwords--didn't go away. The keys used are still susceptible to passive dictionary attacks. Other VPN protocols such as IPsec are not subject to these same problems, and they hope that use of this protocol will decline as IPsec gains prominence.

It's results like these that reinforce the perception that Microsoft does not know jack about cryptography or data security in general.

Log in or register to write something here or to contact authors.