FreeRADIUS EAP-TLS Auth. Issues

[Gerald Vogt]

Well, you'll probably understand that someone wouldn't want to make some 
bigger changes to the source, if someone hasn't written code in C for 
more than 20 years, and considering the way you shoot off replies of 
people here and on github, I'll surely expect any patch submitted being 
refused because there's something not the way you want it, not following 
some way or coding style which is somewhere probably documented in length.

And adding new parameters and splitting the use of them to their proper 
causes is definitely not a two-line change.

So please excuse me, if I don't want to spend time on something for 
which I am pretty sure will be mostly wasted time...

And looking at

https://github.com/FreeRADIUS/freeradius-server/blob/57325921a6c6526519d5d6d494627f9d9a3611e3/src/lib/tls/verify.c#L389

it seems 4.x also uses a set of trusted certs in "chain" for the 
untrusted parameter of

int X509_STORE_CTX_init(X509_STORE_CTX *ctx, X509_STORE *trust_store,
                         X509 *target, STACK_OF(X509) *untrusted);

I am very sorry,

Gerald

On 24.01.24 13:24, Alan DeKok wrote:
> On Jan 24, 2024, at 3:22 AM, Gerald Vogt <vogt at spamcop.net> wrote:
>> There is little you can do about this at the moment. I have wrote a while ago that it's conceptually flawed to mix ca path/file configuration for the server side (i.e. how the freeradius tls server builds and presents its chain) with the ca path/file configuration for the client verification. That already makes it hard.
> 
>    Patches are welcome.
> 
>    This is an open source project.  While myself and the rest of the team do a lot of work, our resources aren't infinite.  What would be appreciated much more than "you're wrong" is patches to fix it.
> 
>> Thus, an untrusted intermediate ca certificate in the chain is acceptable. Just the chain must verify to a root ca in the trust store.
> 
>    Which is why OpenSSL provides for a CA directory.  The hope is that OpenSSL can figure things out, by being passed the right set of parameters.
> 
>    Sadly, this isn't the case.
> 
>> The trouble is how to configure it properly in freeradius as it only has certificate_file, ca_file and ca_path, and their mixed used for the tls server certificate (chain) and the tls client verification. The comments in the configuration files on those options being misleading or inaccurate in some aspects, too.
> 
>    It would be productive to supply patches which correct documentation errors.
> 
>> It's the same way any browser works: there are trusted root cas and the chain validation of any webserver is built from there, learning the intermediate CAs on the way without giving them explicit trust.
> 
>    Oddly enough, FreeRADIUS calls the same OpenSSL API calls that the browsers use.  The theory is that by supplying a trusted root CA, OpenSSL can then validate the chain, including any intermediate CA.
> 
>    The main issue with FreeRADIUS is that the default configuration assumes that both the server cert and the client certs are derived from the same root CA.  When that isn't the case, it becomes more difficult.
> 
>    Happily, source code is available.  It should be possible for an enthusiastic and positive person to add new configuration parameters, and have the server call different OpenSSL APIs to add new behavior.  Then, also to add documentation, and update the existing documentation.
> 
>    Until that happens, v3 won't change.
> 
>    For v4, we've substantially reworked the TLS code and configuration.  If that still doesn't meet your needs, we again welcome patches and documentation updates.
> 
>    Alan DeKok.
> 
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html