Talk:Point-to-Point Tunneling Protocol

ANswer File is not upadets —Preceding unsigned comment added by 122.160.78.51 (talk) 17:17, 22 March 2010 (UTC)

Requesed Move

reason=naming conventions: article title of a proper noun should be capitalized. This is an official legal name.

• e.g. Layer 2 Tunneling Protocol—Preceding unsigned comment added by Anon lynx (talk • contribs)

• Unsure. Is this really a proper noun within the meaning of WP:NC? The status as an official or legal name is not the primary question, the question rather is whether it is normally used as a proper noun. Andrewa (talk) 12:36, 27 October 2008 (UTC)

References

Link to PPTP password sniffing software

I just want t see what everyone else thinks on this link at the bottom of the article which links to a piece of software allowing users to break into a PPTP connection. The site supplying the software claims that it's meant for showing the risks of using PPTP, but in the wrong hands it could potentially be used for maliciously against a network. Personally I don't like the idea of giving this software publicity to like this.

That's frankly silly, shall we expunge all mention protocol holes and vulnerabilities in implementations from Wikipedia for fear of giving them publicity? --82.26.125.76 (talk) 11:54, 19 April 2010 (UTC)

Hi can you connect my vpn Iinksik (talk) 00:44, 21 November 2013 (UTC)

Is PPTP insecure by design?

Are long passwords a real protection?

No. Looking at the asleap code it seems that any password that can be found in a dictionary can be broken, in other words it appears to be similar in nature to cracking non-shadowed encrypted passwords from /etc/passwd. Pick a password that can't be found in a dictionary (combine letters/numbers/other characters etc.)

Inaccuracies and NPOV

OK, correct me if I'm wrong, but for a start it isn't the PPTP protocol itself that is weak, but the MS-CHAPv2 protocol. Here http://blogs.zdnet.com/Ou/index.php?p=21 it is suggested that EAP-TLS with PPTP is secure.

Also, being an encyclopedia article, I think it's hardly correct to make broad unsubstantiated claims like "PPTP is broken" and it "should not be used." I'm not saying PPTP/MSCHAP is a good system, but if you want to keep NPOV then the article should be written from a neutral, factual point of view, rather than giving an opinion/advice IMHO. E.g. state that "Some people believe PPTP is insecure" and give references, or even "this study shows PPTP is insecure in certain situations" and quote the study.

It should be noted that Schneier's 1998 article is based on the outdated MS-CHAP protocol, not the newer MS-CHAPv2. He has another article on his website analysing the v2 protocol and outlining the insecurities fixed in that version.

I agree that this section is badly POV, so I have moved it to the discussion area for more work. I checked on a local network security expert, and he agreed with my assessment.

PPTP Vulnerabilities

The security of PPTP has been entirely broken and PPTP installations should be retired or upgraded to another VPN technology. The ASLEAP utility can quickly recover passwords from PPTP sessions and decrypt PPTP VPN traffic. PPTP attacks cannot be detected by the client or by the server because the exploit is passive.

The failure of PPTP as a VPN protocol is caused by cryptographic design errors in the Cisco LEAP and Microsoft MSCHAP-v2 handshake protocols, and by key length limitations in MPPE. Both LEAP and MSCHAP-v2 derive session keys from user passwords, which are cryptographically weak.

Novasource 03:07, 21 January 2006 (UTC)

Any progress on implementing this section? I'm looking forward to it! --Damsleth 08:22, 29 June 2006 (UTC)

A quote was removed by "The Tao of Mac" because a self-proclaimed computer expert (lacks appropriate security credentials) commented on PPTP in a very short 2 sentence article. Check your sources people. The previously mentioned zdnet is more objectional because they are a)in the field of security b)probably have a better understanding of it and c)contacted Microsoft about PPTP and have responded to their suggestions appropriately. The ZDnet article should be linked in the Wikipedia article. —Preceding unsigned comment added by Moosebutter (talk • contribs) 00:06, 29 April 2008 (UTC)

I'd like to rewrite the security section. As it stands, the section does not explain in any level of detail as to the known problems with PPTP and those that have been fixed in the past. As of now, the problems relate to the use of passwords as the generator for the crypto keys for the rest of the communications encryption, when using MSCHAPv2. Novasource comments above are accurate, but need breaking down into pieces for better clarity. If there are no objections I'll update this section in a couple of weeks. Fancy steve (talk) 09:54, 18 December 2009 (UTC)

remove cruft ?

I am not sure that I understand the following, but it sounds like a bit of useless historical cruft:

Full MPPE support was added to the Linux 2.6.13 branch that is maintained by Andrew Morton. SuSE Linux 10 was the first Linux distribution to provide a complete working PPTP client. Official support for PPTP was added to the official kernel release in version 2.6.14 on October 28, 2005.

Perhaps a more simple up to date phrasing would sound like this:

Full MPPE support was added to the Linux version 2.6.14 on October 28. SuSE Linux 10 was the first Linux distribution to provide a complete working PPTP client. —Preceding unsigned comment added by 144.226.173.68 (talk) 19:08, 2 October 2008 (UTC)

Performance and encryption

Perhaps most SOHO routers don't implement MPPE encryption, thus leaving the tunnel actually insecure. So why do they lose routing performance dramatically, as much as 2—3 times, when in PPTP mode (as compared to non-tunneled mode)? The same situation tooks place on PPTP server when an unencrypted tunnel is established: the CPU load raises a lot for a smaller amount of traffic per unit of time, as compared to much bigger traffic volume of non-tunneled mode. Without encryption and with almost the same MTU size, what makes them spend such a great slice of computational power? 217.172.21.161 (talk) 05:20, 9 February 2009 (UTC)

Other VPN protocols

I've removed the following Other VPN Protocols link set as it is now primarily found on the main VPN page:

• IPsec
• OpenVPN
• HIP Host Identity Protocol
• L2F Layer 2 Forwarding Protocol
• L2TP Layer 2 Tunneling Protocol
• PLIP Parallel Line Internet Protocol
• PPP Point-to-Point Protocol
• SLIP Serial Line Internet Protocol
• SSL/TLS Secure Sockets Layer / Transport Layer Security

Fancy steve (talk) 00:36, 7 January 2010 (UTC)

huh

"The PPTP GRE packet format is non standard, including an additional acknowledgement field replacing the typical routing field in the GRE header." This sentence makes no sense. It's implying we already knew that GRE has some "routing field", which doesn't mean anything to us. —Preceding unsigned comment added by 207.35.173.122 (talk) 15:36, 8 October 2010 (UTC)

Certificates

I think is wrong to say that certificates is not a viable authentication option for many remote access installations:

EAP-TLS is seen as the superior authentication choice for PPTP [2]; however, it requires implementation of a Public Key Infrastructure for both client and server certificates. As such it is not a viable authentication option for many remote access installations. —Preceding unsigned comment added by 79.138.181.159 (talk) 21:32, 11 December 2010 (UTC)

Microsoft ?

This article says that PPTP is from Microsoft, 3com, and others, while L2TP says that it is from USRobotics.

Which is correct? --MathsPoetry (talk) 08:01, 21 September 2013 (UTC)