Hi Greg,
On Wed, Aug 10, 2016 at 11:30:14PM +0000, Greg Smith wrote: > Hello. > > I have some devices in the field that have all PPP authentication > turned off for PPP. Now that lwIP supports MSCHAPv2 and MPPE (in the > 2.0.0 betas), I'd like to enable those features on my devices to > encrypt the traffic. But I also need to support older units that are > running older lwIP versions and don't have authentication support. > > If I ppp_set_auth(, PPPAUTHTYPE_ANY,,) in my startup code, I can get > peers to connect with both no authentication and MSCHAPv2 > successfully. (Yea!) Yes, but it only works because MSCHAPv2 is tried first. Anyway using PPPAUTHTYPE_ANY have security considerations to take into account, it mostly renders authentication useless, this is just to say it for future readers, I'm sure you already know that :) > However, if I then try ppp_set_mppe(pppPcb, PPP_MPPE_ENABLE | > PPP_MPPE_REFUSE_128); (with or without the REFUSE flag), my clients > with no authentication fail because MPPE is "required". (LwIP > responds with "MPPE required, but MS-CHAP[v2] auth not performed.".) > > I'd like to make it so MPPE is only required if MSCHAPv2 negotiates. > (Alternately, don't require MPPE if no authentication is negotiated, > but require it (and fail) if any other form is negotiated.) Is there > a way to do this? Or is that behavior completely unsupported? You are right, this is currently not supported. The problem here is that allowing no encryption if the peer does not support encryption while encryption is enabled makes it vulnerable to a downgrade attack[1] up to using clear text. Maybe I could add a flag to MPPE configuration to allow it, something like PPP_MPPE_ALLOW_CLEARTEXT, with a huge warning about the security implication because it makes MPPE close to useless. > I've thought about using PPP_NOTIFY_PHASE in some way, but I haven't > explored that yet. Would that be viable (even if clunky) to manually > do ppp_set_mppe after MSCHAPv2 negotiates? Or is even that poor > practice to change LCP options in the middle of the negotiation? I'm pretty sure this idea is actually working :-) As long as ppp_set_mppe is called inside the lwIP thread for !NO_SYS systems, I see no reason it couldn't work. Note you have to clear MPPE flags after authentication phase and before CCP, else MSCHAPv2 is not going to prepare keys for MPPE. MPPE is clearly misdesigned, this is huge hack between MSCHAPv2 and CCP… it breaks all the PPP basic design about auth and control protocol isolation from each other. There is worse, the way keys are generated can't have more entropy than the chosen password because keys are only derived from the password hash, and it gets even worse because transformations done on the hash to make it "more" random actually reduce its entropy to a weak 56-bit key, that was designed back in the day were Microsoft knew nothing about encryption and they did it wrong. By the way, it can only uses the RC4 cipher, which is considered weak today.[2][3][4] It was enough for what I needed though, this is why I added it, I only wanted to prevent anyone from sending valid command packets to our equipment just by knowing its IP address. If someone breaks encryption and send the packet which we avoided being received, then we will "Actually, I'm not even mad, that's amazing" [5] :-) Sylvain [1] https://en.wikipedia.org/wiki/Downgrade_attack [2] http://security.stackexchange.com/questions/45509/are-there-any-known-vulnerabilities-in-pptp-vpns-when-configured-properly [3] http://superuser.com/questions/171277/mppe-forcing-strong-passwords-enough-to-make-pptp-secure [4] https://www.schneier.com/academic/archives/1999/09/cryptanalysis_of_mic_1.html ( abstract: https://www.schneier.com/academic/pptp/ ) [5] http://s2.quickmeme.com/img/34/34bde2c7eac4b12fec8ebfad5b806f0f5c12f2f7493fd40ca2e01f5d6c84901e.jpg
signature.asc
Description: Digital signature
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
