![]() | ![]() |
There's been a great deal of controversy over the security of PPTP. Some of this has been due to weaknesses in Microsoft implementations of PPTP, many of which have been fixed. However, there are some design weaknesses in PPTP as well.
icrosoft's implementation also has problems with the encryption. Microsoft offers two levels of encryption, both using the symmetric key encryption algorithm called RC4; one uses a 40-bit key, and the other uses a 128-bit key. (See Appendix C, "Cryptography", for more information on RC4 and the importance of key length.) The 40-bit RC4 algorithm is not particularly strong to begin with, and icrosoft weakens it further by basing the key on the user's password, so that a user will have multiple sessions with the same key. The longer a key is used, the stronger it needs to be, and the time between password changes may be a very long time indeed.
When 128-bit keys are in use, Microsoft bases the key on the user's password and on a pseudo-random number so that it's different for each connection. This is a major improvement, although using the user's password does reduce the number of probable keys and makes it important for PPTP users to have good passwords.
ost PPTP implementations, including Microsoft's, are susceptible to problems with control negotiations. As we pointed out earlier, these negotiations take place before the client authentication, which means that any attacker can send them. It's therefore extremely important for servers to be able to deal with bad negotiations, but in fact, many servers will crash if they receive garbled negotiations, and some will crash even when sent random garbage that bears no resemblance to a valid negotiation. Although Microsoft offers an option to control PPTP access by source IP address, it's enforced on the GRE tunnel, not on the TCP-based negotiation. If you are doing PPTP from known source addresses, you can protect the PPTP server with a packet filter in front of it; if you are not, you have no choice but to live with these denial of service attacks.
Direction | Source Addr. | Dest. Addr. | Protocol | Source Port | Dest. Port | ACK Set | Notes |
---|---|---|---|---|---|---|---|
In | Ext | Int | GRE |
[37]
|
[37] |
[38]
|
Tunnel data, external client to internal server |
Out | Int | Ext | GRE | [37] | [37] | [38] | Tunnel reply, internal server to external client |
In | Ext | Int | TCP | >1023 | 1723 |
[39]
|
Setup request, external client to internal server |
Out | Int | Ext | TCP | 1723 | >1023 | Yes | Setup response, internal server to external client |
Out | Int | Ext | GRE | [37] | [37] | [38] | Tunnel data, internal client to external server |
In | Ext | Int | GRE | [37] | [37] | [38] | Tunnel reply, external server to internal client |
Out | Int | Ext | TCP | >1023 | 1723 | [39] | Setup request, internal client to external server |
In | Ext | Int | TCP | 1723 | >1023 | Yes | Setup response, external server to internal client |
[37]GRE does not have ports. GRE does have protocol types, and PPTP is protocol type hexadecimal 880B.
[38]GRE has no ACK equivalent.
[39]ACK will not be set on the first packet (establishing connection) but will be set on the rest.