It's no secret that PPTP has a bad rep these days, but why is PPTP VPN considered to be unsafe and how bad is it really?
In this post, we shine the spotlight on PPTP, covering its origin story, its well-known flaws and just how it has managed to stick around this long.
To gain a better understanding of how and why the PPTP protocol came about, it helps to take a deep dive into the history of data transfer and how computers worked back in the 70s and 80s.
Data transfer & serial ports
Once there was a time when a computer’s most important data port was the serial port. Introduced in 1960 as RS-232, it was the primary port to get data going in and out of the computer. When two computers were connected via their serial ports, that connection could have been seen as an early form of network connection.
By using a modem like the one shown below, it was possible to transform serial data into acoustic data and back again, allowing serial data to be transported over an analog phone line. This made it possible to connect computers together all over the globe.
If all you wanted to transport was raw data, using a serial modem connection directly was okay. However, if you wanted to run something like an internet connection over a serial line, a data link protocol was required, as the IP protocol cannot directly be used on raw data lines. This is because it always requires some kind of data link protocol below it.
Serial connections did not come with such a protocol and modems only provided primitive data flow control and simple error detection (e.g. parity bits).
SLIP and PPP
One famous protocol that allowed tunneling IP traffic over a serial line was named SLIP (Serial Line Internet Protocol) and was standardized in 1988. Unfortunately, SLIP was rather basic and limited, which is why by 1989 the more complex PPP (Point to Point Protocol) was standardized and soon became the de-facto standard for connecting to the internet via a modem line.
PPP supported automatic configuration of network parameters (like IP addresses and DNS settings), user authentication, data compression, sophisticated error detection, and was able to tunnel multiple virtual connections over a single physical connection; SLIP, on the other hand, supported none of that.
The origins of remote work
In the late 1980s, remote access to a company network was achieved by hooking up a dial-in gateway to the phone network and branch offices or teleworkers would just dial into that gateway. Data encryption and integrity were not viewed as a big issue at that time, since phone lines were considered to be sufficiently secure.
However, soon the internet received its own lines and separated itself from the phone network into a communication network of its own. Phone lines were no longer state of the art and the burning question was: how can branch offices and teleworkers continue to gain remote access without having to use phone lines but by instead using the internet directly?
(As we know today, the answer to that question is VPN, but at that time this term did not even exist!)
In an attempt to utilise the internet for remote access, Microsoft came up with the following idea: Why not continue to use PPP and tunnel it over the internet? PPP doesn't care what kind of hardware or software protocol is used to transport the PPP data, so instead of using a serial connection below PPP, it's also possible to use an internet connection.
In addition, a PPP gateway doesn't need to know if the PPP packet it’s handling arrived from a modem via a telephone line or from a network card via some kind of Internet line. This means there is little that needs to be changed for existing deployments, as it allows running both kinds of connections in parallel; ensuring there is a smooth transition for companies from dial up modems to direct internet connections at their own pace.
The new protocol was named PPTP (Point-to-Point Tunneling Protocol) and was finally standardized in 1999, after about 4 years of development.
How does PPTP work?
The idea was as follows: First a client would contact a PPTP gateway using a normal TCP connection (TCP port 1723) and negotiate that it wants to establish a PPTP tunnel. You can compare this to calling a phone number, having the other end accept the call and performing a modem handshake.
Using this protocol layer, it is also possible for a PPTP gateway to instruct a client to use a phone connection instead, or for a client to request for a gateway to call it back on a phone line. That way, a phone link could be established from gateway to client (which means the gateway has to bear the phone costs instead of the client).
Once this part is done, the client directly sends PPP packets to the gateway's IP address; wrapping the PPP packets into GRE packets.
What is GRE?
GRE (Generic Routing Encapsulation, standardized in 1994) is a low level IP protocol from Cisco that runs directly on top of the IP protocol layer. It can be used instead of TCP and UDP and is typically used to transport data packets that do not terminate at the receiving host but are to be routed onwards from there.
In other words, it allows the layer 3 IP protocol to be used as if it was a layer 2 data link protocol for the purpose of transporting packets from router to router.
Problems with PPTP
On the surface, PPTP appeared to be a great solution which required few changes to existing clients and gateways, but there was one issue: While phone lines provided some physical protection (hacking the phone network to get access to an active phone call was nearly impossible) hacking an internet router to send you a copy of all data it forwards for a certain GRE connection was way simpler.
Furthermore, many of these routers were also owned by private ISPs (Internet Service Providers) who could easily see what data was being exchanged or even manipulate the data being exchanged.
The result? When transporting PPP over the internet, encryption was no longer an option but a requirement. Yet neither PPP nor GRE had any support for data encryption. The solution to this problem was MPPE (Microsoft Point-To-Point Encryption).
How MPPE works
PPP doesn't know encryption but it does know compression. For PPP, compression is a black box. It feeds the data into a compression plugin and this plugin then transforms the data to hopefully make it smaller. However, if the data stays the same size or even gets bigger, that's also okay with PPP.
Both compression and encryption transform data, but they do so for different purposes (one tries to make data smaller, on tries to make it unreadable) but as PPP doesn't care, MPPE pretends to be a compression, when in fact it is an encryption, and PPP clients and servers don't have to know anything about MPPE, for them it's just another compression plugin.
PPTP is still very widespread, but there are four clear reasons why PPTP VPN should no longer be used today:
1. Lack of GRE support
Since PPTP is based on GRE, it requires NAT routers to have explicit support for GRE (often called PPTP Passthrough), yet many cheap NAT routers can only handle TCP and UDP packets. Without GRE support, it is possible to establish a TCP connection and request a PPTP tunnel but any attempt to send PPP packets to the gateway will fail. Especially with carrier grade NAT performed at the ISP, PPTP often is no option at all, since sometimes GRE is not supported by these NAT gateways.
2. SHA1 insecurities
To perform encryption, a cryptographic key must be generated. Since PPP knows no encryption, it also knows no key exchange method, so MPPE derives the cryptographic keys from the user authentication exchange using the SHA1 hash algorithm. The problem? SHA1 is no longer considered secure for cryptographic operations as it is known to be vulnerable to attack.
3. DES insecurities
To be able to derive cryptographic keys for MPPE, the user must authenticate using the MS-CHAP or MS-CHAP v2 authentication method. The problem with these methods is that they use DES encryption instead of a cryptographic hash to mix password and challenge data. DES encryption uses 7 byte keys, so the key space is only 56 bits which is way too small for today's computers. As a result, high end PCs can break DES encryption in just a few days using brute force (just trying all possible key combinations). There are even hardware DES crackers that can break DES in less than a single day.
4. RC4 insecurities
The actual data encryption that MPPE uses is RC4 and RC4 is also no longer considered secure. There are known attacks that can break RC4 in less than a week if you only have enough computational power and capture enough encrypted data. It is assumed that government agencies have enough computational power to break RC4 in a matter of hours.
While this surely sounds horrifying, there are two things one has to keep in mind. For one, even a weak encryption is better than no encryption at all. If the alternative to PPTP is to use something that is unencrypted or possibly even uses a weaker encryption, PPTP surely still is the better option.
While there are way better VPN protocols to choose from, replacing a complex PPTP setup with a different protocol may mean a major network reconstruction, especially at enterprise level.
Secondly, one must keep in mind that even though all parts of the PPTP encryption are attackable, these attacks are expensive and time consuming; meaning not every existing PPTP connection on earth can be broken. Sure, a secret agency could probably break specific PPTP connections fairly easily, but they cannot break millions of PPTP connections each day. Even their resources are limited.
So unless the data you will be sending over PPTP are of a certain value to an attacker, nobody will invest the time or the money to break your connection, it's just not worth it.
PPTP surely is dying. In fact, it has been dying for years, but it's a rather slow death.
The use of PPTP will slowly fade out in the future, but as long as Microsoft supports PPTP in all their client and server products (including their latest products!) and as long as big network vendors still offer it on their VPN concentrators as the ultimate fallback solution if nothing else is possible, you can expect PPTP to be around for many more years to come.
If you want to replace PPTP with something more secure, yet cannot get rid of PPP because your entire network stack depends on it, there is a secure and fast alternative: L2TP or more precisely, L2TP over IPsec, which combines PPP and IPsec, so you can keep using PPP and all its features but profit from the high security level and speed of IPsec.
On the other hand, if you don't depend on PPP, you should drop that protocol layer altogether and consider using IPsec directly, since as long as all you want is to tunnel IP traffic, that's something IPsec is capable of all on its own without any additional intermediate protocol layer.
Why VPN Tracker?
Although we advise against using PPTP where possible, we also acknowledge that it's an integral part of many enterprise network setups and for this reason, are the only VPN client to offer PPTP VPN support for the latest macOS.
Whether you're still using PPTP or looking to make the switch to a more secure protocol like IPsec, VPN Tracker is the best remote access solution for Mac, iPhone and iPad.
Your VPN Tracker benefits
- Securely connect with your home and office networks
- Use your own gateway
- Support for all major VPN protocols, including PPTP! (Mac exclusive)
Preconfigured profiles for 300+ VPN devices
- Expert productivity features for teams
- For Mac, iPhone, iPad
- Explore all features