FreeRADIUS EAP-TLS Auth. Issues

[Gerald Vogt]

On 24.01.24 16:06, Alan DeKok wrote:
> On Jan 24, 2024, at 9:44 AM, Gerald Vogt <vogt at spamcop.net> wrote:
>> I tried. You have closed the issue. You see my point? You consider opening an issue just as critique and refuse from the very beginning.
> 
>    For the record, the issue is this:  https://github.com/FreeRADIUS/freeradius-server/issues/5012
> 
>    It has a long discussion where you were asked repeatedly to explain what's wrong with the current configuration / behavior, and to offer better suggestions.  That didn't happen.

On the contrary, it's all in the initial message. I wrote what's the 
problem with the current configuration and why it's an issue to mix up 
use of ca files or paths for both server and client configuration.

I have outlined, on a high, conceptual level what configurations are 
necessary or possible to cover all those aspects.

I have also gave an example how it is does it httpd mod_ssl and that 
there is a good reason why they have separated it.

So I have made suggestions on how to improve this, how to have clear and 
distinguished configuration parameters for the configuration of the tls 
server and the tls client verification.

You basically answered that you can do the things that you want to do so 
what's wrong? It works.

I have pointed out how the comments for the configuration parameter are 
confusing or misleading. I don't know, where exactly those parameters 
are used for. I can only read the comments and try to understand what 
the purpose is or how they map to the standard openssl parameters like 
for verify.

So how do you think I should know when to put the server CAs into 
certificate_file and when not. Or when you can use ca_file. Or ca_path. 
Or both. Or only either. When using client certificates. Or when not 
using client certificates. It is unclear, what it does exactly. So 
expecting someone else to clarify the documentation is kind of futile.

If it's so easy and so clear, why don't you write it simply into the 
documentation? If I point out discrepancies or what's unclear but you 
shut it down.

Thus, if you write " It just takes a little bit of work", then that is 
not helpful if that work is required because it's unclear. You may as 
well end up with a configuration which works but accepts much more 
certificates then indented. The trouble is, most people won't notice 
that until there is a problem.

Thus, as I write in the initial message of that issue: conceptually the 
tls server configuration and tls client verification are two completely 
different aspects which can rely on two completely different ca sets. 
Thus, conceptually it would be better separate those. But currently, if 
I understand correctly, the tls server can build its chain from ca_dir 
and at the same time the client verification can use ca_dir, too.

Also, assuming that people know that the option "ca_dir" is used as 
openssl "CApath", thus requires the hashes, well... "We do not include 
... all of OpenSSL documentation". Let the dumb user figure it out 
themselves. Why should the docs indicate that ca_dir is CApath and 
requires c_rehash (did FR 2.x mentioned c_rehash?)

You don't see how it's unclear. So why bother with anyone who finds it 
unclear?

Not to mentioned that arr2036 also wrote "I found that extremely 
confusing and ended up redoing a lot of the validation logic manually."

So really, I am not the only one...

>    So the reported problem ended up being "I don't understand how it works. I don't know how it should work.  I don't know how to change it".
> 
>    There is no action we can take to fix that.  Which is why the issue was closed.

Yes, excellent move to shut down any attempt to clarify it. It is 
'extremely confusing'...

>> Yes. If the person who evaluates your attempt, has a certain attitude to shoot everything down, you'll obviously ask yourself why should you even try.
> 
>    A simple "git log" of the server shows that's not true.  There are many, many, people who have contributed.  But they take the time and effort to do so.

Well, maybe you didn't shut them down immediately. I would participate 
to the best of my abilities if you would shut me down with your arrogant 
attitude.


> 
>> I am more than willing to help as I do in a lot of other projects, but I can always only contribute to the extent of my abilities (and the time I have).
> 
>    As can I.  Yet for some reason, that excuse is valid for you, but you don't think it's valid for me.
> 
>    i.e.  You don't have the time or inclination to work through the issue you opened, and you think that's fine.  But if I don't do that work and instead close the issue, then I'm a bad person.

Yes. You have closed the issue instead of giving me an opportunity to 
make myself clearer. So you don't have the time or inclination to work 
through the issue I have opened, trying to understand the issue and how 
'extremely confusing' it all is. And how that is even much harder for 
people who haven't dealt with openssl for many years and understand the 
basic concepts of it all.


> 
>> You are disappointed that there is a large group of people who have suggestions how to improve something or who find issues in how things are, but who are not able to contribute significantly...
> 
>    At the minimum, I expect contributions to be something more than "I did a bunch of stuff.  It didn't work the way I expected.  You need to fix it".

I did a bunch of stuff.

It works for me. And I think the way I did it I think it only works the 
way I expect it and that there are not side effects which are allowed.

But I only got to that point but not really following what is clearly 
mentioned in the comments.

I got to that point by briefly checking the source code to get some idea 
where those parameters might be used and how they map down to the common 
openssl configurations for tls servers and client verification.

I got to that point because I think I understood the mixed used of some 
of those parameters for tls servers and client verification from that, 
thus separating it by a certain way of configuration, from experience 
with openssl.

So it works and I hope it really only works the way I expect it.

But to clarify the documentation is difficult if you don't have a deeper 
understanding of where everything is used exactly. It'll takes me hours 
to figure that out, what a developer just knows...

>> You can either pick that up, show some interest and start a discussion which could well go deeper, or you can simply be disappointed and tell people that they "have time and energy to criticize, but none to contribute", expecting them (between the lines) to provides fully finished code patches which you can review.
> 
>    We both know hat isn't what I said.  I've asked you for documentation updates, or for a clearer description of the problem.
Oh. Yes. That's very much what you basically said, whether you call it 
"documentation updates" now. If you asking for a PR that's what you do.

The documentation is unclear. I have to guess what the documentation 
means. You ask me for documentation updates. How am I supposed to give 
you a documentation update from some guesses? That documentation won't 
get any better, it's just another guess.

The problem in the end is, that you don't even acknowledge that the 
documentation is misleading, confusing and sometimes simply wrong. I 
know it's easier to find out that it's wrong, and harder to write it 
correctly, which requires an understanding of it. But that doesn't come 
from a guess deducted from a misleading documentation...

I cannot write documentation on what "ca_file" and "ca_dir" does exactly 
when I don't know what it does exactly and where it's used. It may be 
used for tls server or client verification or both, and maybe only 
ca_file if it's defined or maybe both, or maybe only one in certain 
situations. That is the problem.

How much clearer do you need it?

I can guess and write an update, although I hardly know if it's so much 
more accurate...

>    If you need to lie in order to "win" an argument, that's a lot more problematic than my "negative" attitude of asking you to a little bit of work.

I don't have to win this argument. I know by know that you won't change 
and you won't bother even trying to understand. You always win the 
argument because you have the power and if people don't do what you tell 
them to do then you can just simply shut them down.

>> I would love to participate and contribute
> 
>    Apparently not.

I do. But you really working very hard to make me change my mind. You 
must really think, I have nothing better to do then write lengthy 
replies trying to explain my point, even though I am pretty sure that I 
won't get through to you...

But I suppose it is what it is. If you don't immediately understand an 
issue it's obviously the fault of the other person. I mean in the github 
issue above I wasn't the only one who finds it confusing... And from 
many mails here on this list I think it also should be clear that it's 
confusing.

Anyways, I guess I spent enough time on this. I have explained 
originally to someone else how I understand how it works and how it 
needs to be configured. You don't like that either, but have to put in 
your standard "Patches are welcome", which of course is obviously more 
then rhetoric by you, because you know that it's pretty unlikely that 
the average person would quickly rewrite the use of certificates and 
submit a patch...

I have explained to someone else the trusted and untrusted certificates.

If that's a problem for you or doesn't fit your standards, well, no need 
to repeat your "patches are welcome"...

Over and out,

Gerald