compilation problem deprecated: Since OpenSSL 3.0

[Alan DeKok]

On Aug 29, 2023, at 7:05 AM, Joost Ringoot <joost.ringoot at meteo.be> wrote:
> Meanwhile I found the eapoltest is available in debian as separate package, and it appears to function 

  That's good.

> I have other questions however:
> Is there  an upgrade or current documentation that handles EAP-TTLS?

  I don't know what that means.  Upgrade to... what?  And how to "handle" EAP-TTLS?

  To configure EAP-TTLS for eapol_test, see the eapol_test documentation.  FreeRADIUS also comes with sample eapol_test configurations for TTLS.  See src/tests/*ttls*

> Further I read everywhere on internet that mschap and also mschapv2 is flawed

  Only if:

a) you use plain MS-CHAP across the Internet without TLS

b) you use PEAP, and the supplicant doesn't verify the server certificate.

  We did some tests in 2016 to show how easy it was to spoof WiFi, and steal passwords:

https://networkradius.com/articles/2021/08/04/wifi-spoofing.html

  The good news is that supplicants have gotten better, and now are required to validate the server certificate.  So I wouldn't worry too much.

  The real limitation is what database do you use to store passwords.  If it's Active Directory, then you're stuck using PEAP/MS-CHAP, or TTLS/PAP.

  If you use a database with crypt'd passwords (e.g. Linux /etc/passwd), then you have to use TTLS/PAP.  This is actually the recommended approach:

https://networkradius.com/articles/2022/04/11/is-pap-secure.html

  What is more likely, someone steals the password for one machine, or someone steals your entire password database?

  And any spoofing AP attack for PEAP will also work for TTLS.  The only fix is to use something like EAP-PWD, which doesn't send passwords over the link.


  I'm also working on a document for the IETF which deprecates insecure uses of RADIUS:

 https://datatracker.ietf.org/doc/draft-dekok-radext-deprecating-radius/

  That document addresses these issues, and more.

  In short, your choices for security are limited by what's available, and what's possible.  A simple checklist for security is *not* the recommended approach.  Simple panics about "PAP more secure than CHAP" or "MS-CHAP is insecure" don't help anyone.

  What is required is an educated approach to network security.  Make your system as secure as possible given the constraints you work under.  And fire any "security' person who insists that you follow a checklist approach.

  Alan DeKok.