[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] PPP MPPE "Optional" Support
From: |
Sylvain Rochet |
Subject: |
Re: [lwip-users] PPP MPPE "Optional" Support |
Date: |
Thu, 11 Aug 2016 23:11:38 +0200 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
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