Can PPTP Really Go It Alone?

By Peter Coffee  |  Posted 2003-09-01 Print this article Print

Stronger security of IPSec-based VPNs worth cost.

Regardless of any other network management strengths that a virtual private network may offer, any VPN is fundamentally an encryption-based aid to network security.

The entire case for any VPN is the belief that encrypting data makes it safe to send across a public network and that, furthermore, the security thus gained is worth the associated costs in bandwidth and processing—not to mention the additional costs of VPN products, services and administration. If the encryption protocol used by a VPN installation is unsound—or weakly implemented or carelessly administered with lax key management or other common errors—the exercise can be a waste of time and money.

During the Aug. 19 Ziff Davis Media Inc. Webcast eSeminar on VPN challenges, several attendees asked point-blank questions about the justification for the higher cost of a robust VPN based on IPSec (IP Security) or SSL (Secure Sockets Layer), compared with the lighter-weight PPTP (Point-to-Point Tunneling Protocol) thats supported in a wider range of Windows and that enables a greater number of connections for the same amount of server processing power.

There were serious flaws in Microsoft Corp.s initial implementation of PPTP, including a shortcut to automatic cracking by tools such as L0phtCrack from @Stake Inc., of Cambridge, Mass. (More information is at

Microsofts current PPTP version, using Microsoft Challenge/Reply Handshake Protocol Version 2, or MS-CHAPv2, addressed this vulnerability and added server authentication to prevent masquerade attacks by rogue servers.

Microsoft officials are quick to acknowledge, however, that PPTP merely encapsulates data, failing to address other key concerns of mission-critical network administration. For example, PPTP does not have the necessary tools for preventing a "replay attack," in which an attacker monitors the communications stream and sends previously intercepted traffic to pose as a legitimate participant.

Protocols such as IPSec, in contrast, provide mechanisms to detect the packet sequence disruptions that betray this tactic.

PPTP also has the weakness of relying on passwords, which are often chosen poorly or protected inadequately by their users. IPSec and SSL rely on cryptographic certificates or algorithms that typically provide a stronger form of encryption, but many implementations use certificates associated with machines rather than users.

The user who leaves a machine logged in thats physically accessible to others, or the user who enables automatic log-in features on either kind of VPN, makes the security of the network only as good as the physical security that protects the users office—or, worse still, the users portable device.

System builders must appreciate that in the domain of security, every convenience comes at a price. SSL-based VPNs accommodate the heterogeneity of Web clients to offer service to a wide range of users and devices, but that tolerance of differences also creates possible security loopholes (for example, the risk of automatic fallback to an easily cracked 40-bit key if a user logs in with an outdated browser).

IPSec clients are less tolerant. Server-side attacks on SSL-based VPNs might succeed if users are too casual in dismissing warnings about possibly bogus security certificates, potentially enabling man-in-the-middle attacks. IPSec clients leave less to the users discretion.

Anyone considering VPN alternatives must look at all of the implications—practical, as well as theoretical—of each offered choice.

Technology Editor Peter Coffee can be reached at peter_coffee

Peter Coffee is Director of Platform Research at, where he serves as a liaison with the developer community to define the opportunity and clarify developers' technical requirements on the company's evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter company's first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel