1
0

PROTOCOL-SECURITY 4.1 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788
  1. Protocol Security
  2. Summary
  3. by Peter Mueller
  4. PPTP is known to be a faulty protocol. The designers of the protocol,
  5. Microsoft, recommend not to use it due to the inherent risks. Lots of
  6. people use PPTP anyway due to ease of use, but that doesn't mean it is
  7. any less hazardous. The maintainers of PPTP Client and Poptop
  8. recommend using OpenVPN (SSL based) or IPSec instead.
  9. (Posted on [1]2005-08-10 to the [2]mailing list)
  10. _________________________________________________________________
  11. Why not use PPTP?
  12. by James Cameron
  13. The point to point tunneling protocol (PPTP) is not secure enough for
  14. some information security policies.
  15. It's the nature of the MSCHAP V2 authentication, how it can be broken
  16. trivially by capture of the datastream, and how MPPE depends on the
  17. MSCHAP tokens for cryptographic keys. MPPE is also only 128-bit,
  18. reasonably straightforward to attack, and the keys used at each end
  19. are the same, which lowers the effort required to succeed. The obvious
  20. lack of two-factor authentication, instead relying on a single
  21. username and password, is also a risk. The increasing use of domestic
  22. wireless systems makes information capture more likely.
  23. However, that doesn't mean people don't accept the risks. There are
  24. many corporations and individuals using PPTP with full knowledge of
  25. these risks. Some use mitigating controls, and some don't.
  26. Many people seem to judge the security of a protocol by the
  27. availability of the implementation, the ease of installation, or the
  28. level of documentation on our web site. Improving the documentation is
  29. the purpose of this web site, and we aren't doing that in order to say
  30. anything about the risks of the software! Any judgement of security
  31. should be rigorously applied to the design and implementation alone.
  32. PPTP on Linux, and Microsoft's PPTP, both implement fixes for
  33. vulnerabilities that were detected years ago in Microsoft's PPTP. But
  34. there remain the design vulnerabilities that cannot be fixed without
  35. changing the design. The changes needed would break interoperability.
  36. We can't change the Linux PPTP design, because it would stop working
  37. with Microsoft PPTP. They can't change their design, because it would
  38. stop working with all the other components out there, such as Nortel
  39. and Cisco, embedded routers, ADSL modems and their own Windows
  40. installed base.
  41. The only option then is to deprecate the product and promote the
  42. replacement. Microsoft promote something else. Our choice for Open
  43. Source systems is OpenVPN or IPsec.
  44. Level of acceptance isn't a good indicator of risk either. Some have
  45. said that the shipping of MSCHAP V2, MPPE and PPTP in Linux
  46. distributions is an indication of design security, but that's not the
  47. reason. It's for interoperability. As an example, see how Linux
  48. distributions still ship telnet, ftp, and rsh, even though these
  49. components are insecure because they reveal the password in cleartext
  50. in the network packets. The same can be said of many other components
  51. and packages.
  52. Our recommendations are;
  53. 1. do not implement PPTP between open source systems, because there's
  54. no justification, better security can be had from OpenVPN or
  55. IPsec,
  56. 2. do not implement PPTP servers unless the justification is that the
  57. clients must not have to install anything to get going (Microsoft
  58. PPTP is included already), and be aware of the risks of
  59. information interception,
  60. 3. do not implement PPTP clients unless the justification is that the
  61. server only provides PPTP, and there's nothing better that can be
  62. used, and again be aware of the risks of information interception.
  63. (Posted on [3]2005-08-10 to the [2]mailing list)
  64. References
  65. 1. http://marc.theaimsgroup.com/?l=poptop-server&m=112369621702624&w=2
  66. 2. http://pptpclient.sourceforge.net/contact.phtml#list
  67. 3. http://marc.theaimsgroup.com/?l=poptop-server&m=112365342910897&w=2