From mboxrd@z Thu Jan  1 00:00:00 1970
From: Peter =?utf-8?q?M=C3=BCller?= <peter.mueller@link38.eu>
To: development@lists.ipfire.org
Subject: Re: [PATCH] use CHAP for dial-in as default
Date: Mon, 04 Dec 2017 17:40:05 +0100
Message-ID: <20171204174005.7c16f4e4.peter.mueller@link38.eu>
In-Reply-To: <1511267125.4838.572.camel@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2981051579020292245=="
List-Id: <development.lists.ipfire.org>

--===============2981051579020292245==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hello,

sorry for the late reply.

> Hi,
>=20
> On Mon, 2017-11-20 at 19:30 +0100, Peter M=C3=BCller wrote:
> > Hello,
> >  =20
> > > Hi,
> > >=20
> > > I am not really sure if this would improve security - although the prot=
ocol
> > > itself would of course.
> > >=20
> > > Do we know how compatible other ISPs are with CHAP? I know at least one=
 that
> > > only supports CHAP and so we would break compatibility with them since =
it is
> > > probably not very obvious. =20
> >=20
> > I am afraid I did not get this. If the ISP supports CHAP only, everything=
 is
> > fine, isn't it?
> >=20
> > Of course, they are certainly ISPs which do not support CHAP at all. But =
since
> > existing installations are not changes, this does not break running syste=
ms.
> >=20
> > The main intention of this patch is to make the user be aware of this iss=
ue
> > - they would need to actively select PAP or PAP/CHAP. It is like saying: =
"Yes,
> > you can do so, but this is insecure. Don't say you haven't been warned." =
=20
>=20
> Well, I think we have a very similar problem like we had last week and it is
> convenience & compatibility over security. We have to have a better way to
> decide these things.
Basically yes, but this often depends on the actual problem, so I fear there =
is
no general way to handle this balance between security and usability/compatib=
ility.
>=20
> 100% security would be nice but makes the product unusable for probably 100=
% of
> the user base. If we compromise on some things and chose defaults that are
> inconvenient for 5% of users, we still have 100% security for 95% of the us=
ers.
>=20
> Maybe a rule like that can work... But that would be a different discussion=
 we
> shouldn't have right here.
I agree.
>=20
> > > So, in practice I do not think that this change is worth it, because:
> > >=20
> > > a) it might break compatibility. pppd will always use CHAP if it is
> > > available
> > > already and fall back to PAP when necessary. =20
> >=20
> > True. The point here was to prevent a system from silently falling back to
> > plaintext without anybody knowing it - even though a MITM attack against =
the
> > PPPoE
> > login credentials is somewhat hypothetical. =20
>=20
> A MITM is less than that. It is unpractical and even if it was feasible the=
re is
> not much gain in getting access to the login credentials.
>=20
> The traffic that is being transferred over the connection itself is way more
> interesting and exploitable.
>=20
> > > b) CHAP is not really secure. It is some sort of HMAC-MD5, but the chal=
lenge
> > > is
> > > usually known for someone who can eavesdrop on the wire. So brute-forci=
ng
> > > the
> > > password is easy to do. We would only be left with the protection again=
st
> > > immediate replay attacks which I do not consider a problem since ISPs w=
ill
> > > suspend your account very quickly. =20
> >=20
> > In some way, this is opportunistic encryption (again :-| ): CHAP is
> > undoubtedly
> > broken, but everything - even a base64 encoding - is better than plaintex=
t. =20
>=20
> No, that is security by obscurity and just because it is harder to read for=
 a
> human it is not for a machine. It is precisely the same problem with or wit=
hout
> encoding to base64.
>=20
> > Needless to say, I definitive prefer strong (and enforced) encryption, bu=
t in
> > some scenarios, they are simply not available at the moment. =20
>=20
> I guess what you are looking for is a transport encryption over the Internet
> link.
>=20
> ISPs use IPsec because they don't trust their own infrastructure. That woul=
d be
> a nice to have but unfortunately nothing we can go after.
>=20
> > >=20
> > > c) The Internet connection is a public thing. The user credentials are =
easy
> > > to
> > > socially engineer. Even if the authentication would use CHAP this won't
> > > improve
> > > any security of the data being transferred after that. =20
> >=20
> > True. But preventing against social engineering is out of the range of IP=
Fire.
> > :-) =20
>=20
> Yes.
>=20
> Point is, that the login credentials are a public thing any ways. Some ISPs=
 just
> use the same or random credentials for everyone (especially with LTE). Some
> others use the customers account number which is on every letter...
>=20
> > Feel free to drop this patch if it doesn't suit. :-) =20
>=20
> I didn't say that (yet). I just voiced my concerns. :)
Well, to sum it up, I did not see most points above. In my eyes the patch cre=
ates
more problems than it solves and can be dropped.

Best regards,
Peter M=C3=BCller
>=20
> -Michael
>=20
> >=20
> > Best regards,
> > Peter M=C3=BCller =20
> > >=20
> > > Best,
> > > -Michael
> > >=20
> > > On Sun, 2017-11-19 at 14:47 +0100, Peter M=C3=BCller wrote: =20
> > > > Use CHAP as default setting for PPPoE dial-in connections.
> > > >=20
> > > > Although CHAP does not provide strong transport security
> > > > at all, it is better than submitting credentials in plain text.
> > > >=20
> > > > Enforcing CHAP prevents the system from silently falling
> > > > down to no encryption (MITM attack!).
> > > >=20
> > > > Existing installations remain untouched.
> > > >=20
> > > > Signed-off-by: Peter M=C3=BCller <peter.mueller(a)link38.eu>
> > > > ---
> > > >  html/cgi-bin/pppsetup.cgi | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >=20
> > > > diff --git a/html/cgi-bin/pppsetup.cgi b/html/cgi-bin/pppsetup.cgi
> > > > index 4b45ee50c..a96dce9df 100644
> > > > --- a/html/cgi-bin/pppsetup.cgi
> > > > +++ b/html/cgi-bin/pppsetup.cgi
> > > > @@ -1042,7 +1042,7 @@ sub initprofile
> > > >          $pppsettings{'HOLDOFF'} =3D 30;
> > > >          $pppsettings{'TIMEOUT'} =3D 15;
> > > >          $pppsettings{'MODULATION'} =3D 'AUTO';
> > > > -        $pppsettings{'AUTH'} =3D 'pap-or-chap';
> > > > +        $pppsettings{'AUTH'} =3D 'chap';
> > > >          $pppsettings{'DNS'} =3D 'Automatic';
> > > >          $pppsettings{'DEBUG'} =3D 'off';
> > > >          $pppsettings{'BACKUPPROFILE'} =3D $pppsettings{'PROFILE'};  =
 =20
> >=20
> >  =20


--===============2981051579020292245==--