Unlike IPSec and L2TP+IPSec, a PPTP VPN tunnel is carried over TCP, which means all packets traveling inside the tunnel are delivered reliably—including any tunneled TCP traffic. Therefore, the inner TCP layer never sees packet loss, wreaking havoc with its congestion control mechanisms.
Although the RFC refers to the tunnel as "separate", that's only conceptual. The traffic is carried inside of the single TCP connection. For example, SSH application data delivered over PPTP is wrapped in its usual TCP/IP, then PPP+GRE (the tunnel/"user data" from PPTP's perspective), then forwarded over the TCP/IP control connection to the PPTP server.
L2TP produces a similar wrapping structure, but the outermost connection is UDP instead. Its IP frames are wrapped in PPP+GRE and then delivered to the server over UDP/IP.
Consider L2TP+IPSec first. (At least, my experience with vanilla IPSec has been less than recommendable.)
Update: In the news this year (2012), PPTP's key exchange is broken, and that's actually been known about for years. There's even a cloud service to crack it for you if you're lazy. Current advice is actually:
Never use PPTP.
Reference: Moxie Marlinspike's post detailing the 256 complexity of the attack: the md4(password) is used as DES keys which encrypt the same known plaintext, meaning that each DES encryption can potentially reveal any of the segments of the hashed password string. The plaintext password is not necessary for the protocol. As a bonus, the final DES key is padded with five zero octets since the hash isn't long enough for three DES keys.
No comments:
Post a Comment