FreeRADIUS EAP-TLS Auth. Issues

[Gerald Vogt]

On 24.01.24 21:56, Alan DeKok wrote:
> On Jan 24, 2024, at 2:16 PM, Gerald Vogt <vogt at spamcop.net> wrote:
>> I have explained several points in my second message in the ticket.
> 
>    Which I had responded to, but OK...

Only to a little part.

> 
>>                 #  If ca_file (below) is not used, then the
>>                 #  certificate_file below SHOULD also include all of
>>                 #  the intermediate CA certificates used to sign the
>>                 #  server certificate, but NOT the root CA.
>>
>> O.K. If ca_file is not used, I put the server cert following by the issuing CAs in order except the root ca into certificate_file.
> 
>    That will allow the server to present it's certificate and CA to the client, when the client connects.  That's all true.
> 
>>                 #  When using "ca_file" or "ca_dir", the
>>                 #  "certificate_file" should contain only
>>                 #  "server.pem".  And then you may (or may not) need
>>                 #  to set "auto_chain", depending on your version of
>>                 #  OpenSSL.
>>
>> O.K. In the other case the ca_file or ca_dir are used (i.e. defined) certificate_file should only contain the server certificate. It is a "should" but the average user will hopefully the developers advice.
> 
>    Yes.  If there are multiple CAs, then they can all go into a directory, and OpenSSL will figure it out.
> 
>    That should be a hint as to the real issue:  The FreeRADIUS configuration mirrors the OpenSSL APIs.  If something weird or magic happens, it's almost always because of OpenSSL.
> 
>>                 #  Trusted Root CA list
>>                 #
>>                 #  This file can contain multiple CA certificates.
>>                 #  ALL of the CA's in this list will be trusted to
>>                 #  issue client certificates for authentication.
>>
>> So now it starts: I want to use client certificates. Thus, if I do I can define ca_file.
> 
>    The comments here are fairly clear.
> 
>> Now if I do that, it means I am using "ca_file", i.e. the certificate_file should contain only the server certificate, not the issuing CAs.
> 
>    Yes.
> 
>> This also means, that "ALL of the CAs in this list will be trusted to issue client certificates".
> 
>    Yes.  That's the reason to list multiple CAs: you want to authenticate client certs issued by different CAs.
> 
>> This means, if my client certs and server certs use different CAs I cannot distinguish them, e.g. my server cert could be used for client certificate authentication (if it the server has the attributes set). Something I don't want.
> 
>    So... don't issue client certs from the server CA?  Presumably someone is in charge of it, and can be convinced to do the right thing.

Now, that is incorrect. The instructions tell me to put the server chain 
cas and all cas required for client authentication into the same file 
for ca_file.

Many server CAs issues certs with client and server authentication set. 
Let's encrypt does so. The certificate for the freeradius.org web server 
has it.

And I guess it's pretty common nowadays because many web servers also 
have outgoing backend connection for which they can simply use the same 
certificate. Or our mail servers all have certificates with server and 
client authentication set and use them for client authentication when 
forwarding mails throughout the internal relay network.

It's not my CA and the server certs issued have it both. It's useful and 
common practice. With our old CA we had the option to specify which 
purposes should go into the server cert, but both client and server 
authentication was also an option. With our new CA it always issues 
server certs with client and server authentication purpose set in the 
x509v3 extensions.

>    If you don't trust the CA admins to issue client certs correctly, then no amount of technical changes will fix a political issue.

That is correct. But your assumption that a CA should issue server certs 
witih client authentication included is wrong.

>> So what now? Do I deviate from the "should contain only server.pem"? Or it is wrong to use "ca_file"?
> 
>    Do what the documentation says.  And don't issue client certs from the server CA.  The problem is then fixed.

However, your assumption is invalid that it doesn't help.

> 
>> Second confusion: it says "Trusted Root CA list". It says "Root CA". That does not include intermediates CAs.
> 
>    It includes the intermediate CAs.

It does not say so in the text "Trusted Root CA list". I think there is 
a clear definition of what a root ca is and an intermediate ca is not a 
root ca. I am just reading what is written in the comments and I would 
assume people will do what is written (o.k. many don't but that's 
another story).

>   But in general if you have multiple CAs, just put them into a directory, and let OpenSSL figure it out.

Yes, I know. But again: you don't have to explain to me how openssl 
works. I am just following the instructions from the comments.

I have seen my share of half baked ssl servers which do all kind of 
weird stuff. Thus for a start, I look at the text and what it says, even 
though I can guess what's really behind and can assume that ca_file is 
what is passed to -CAfile in the openssl tools and thus can and should 
include intermediates as well.

>> But without the intermediates, you cannot create a chain from the (server cert only) certificate_file nor can you verify client certs issued by intermediates.
>>
>> So what now? So is this really only a root ca list and the intermediates must go somewhere else? Or is it simply a trusted ca list?
> 
>    This is where I say "try it and see".  And then perhaps submit a GitHub PR to address this issue.  That's a productive approach.

I can try and see and I did and that's why I am not using it the way the 
comments tell me to.

And again: to really submit a meaningful PR I need to understand what it 
really does. Of course, I can start intensive testing to find out what 
it does (at the places I can think of and that I am using). I can also 
search through the source code to find possible other uses I haven't 
thought of or that I don't use. My general presumption is that whoever 
wrote 'Trusted Root CA list' had a reason to write "Root CA list" and 
not "CA list" and why it was specifically attributed as "trusted" 
(following the distinction of the -trusted and -untrusted options of 
openssl).

So yes, I can spend a lot of time to find out and make the best guess I 
can do and submit a PR for something which probably someone who knows 
the code inside and out can clarify in a minute...

>    What isn't productive is to spend hours arguing "the documentation is bad" instead of figuring things out, and fixing it.

Really "figuring things out" means, however, to find ALL places where 
this parameter is used in the source code, understanding what is 
happening at all these places and the consequences.

> 
>>                 #  In general, you should use self-signed
>>                 #  certificates for 802.1x (EAP) authentication.
>>                 #  In that case, this CA file should contain
>>                 #  *one* CA certificate.
>>
>> O.K. Again, if I follow that advice, use self-signed certificates for EAP, thus put only one CA cert into the ca_file, it also requires my server cert to be issued by that CA, when I follow the instructions before.
> 
>    It's a suggestion, not a mandate from heaven written in stone.

It is still what's written there and which people who follow the 
instructions should do. I mean, you are the one you repeatedly tells 
people to read the welcome message and do what it says...

>    If you want to use multiple CAs, you can do so.  Nothing prevents you from doing this.  The documentation explains how to do this.

The text in the comments does not. It clearly says otherwise, even if 
says 'should'.

>    The documentation also suggests best practices.  You're free to follow them, or to do something else.

The comments suggest contradictory and thus confusing best practices.

>>                 #
>>                 #  Directory where multiple CAs are stored.  Both
>>                 #  "ca_file" and "ca_path" can be used at the same time.
>>                 #
>>
>> After all the explanations before telling me what to do when, this now only tells me ca_path is a list of CAs.
>>
>> This is unclear: where is this used? Does the ca_file comment applies and this is a place for (root?) CAs used for client certificates?
> 
>    I'm not sure why there's any confusion.  CAs go either into ca_path, or ca_file.  What's the issue?

The ca_file was for the "Trusted Root CA list" according to the comment. 
It was specifically for client authentication and for the server chain.

ca_path is simply mentioned as "Directory where multiple CAs are 
stored", nothing else. It sounds like just another directory where you 
can store CAs. It's not mentioned as "trusted root ca directory" or similar.

You may know that ca_file and ca_path are internally interchangeably and 
in the same places. But as I wrote before: I have seen my share of bad 
ssl servers which have named configuration options in their own names 
and sometimes using one in the one place and the other in other place.

Thus, just reading the text in the comments ca_file sounds very 
important and special and ca_path is, well, just another directory which 
will be used for whatnot. And things like this can confuse people and 
cause problems and make them ask those "dumb" questions on the list...

>> Or is it just the same like ca_file but with certs stored in a directory?
>>
>> Above first it says "ca_file (below) is not used" and later it says "When using "ca_file" or "ca_dir",". Is this distinction intentionally or is it simply an error of omission?
> 
>    I don't know what the confusion is.  You're given multiple options for configuring things.  The documentation explains what each option does, and how they interact with each other.

The comments don't.

>    The issue seems to be that the documentation suggests you don't always need to use ca_file, and then you see this as somehow a contradiction.  Because other documentation says you can use ca_file and/or ca_path.
> 
>    There's no issue.

Unclear, ambiguous comments or documentation is an issue. It makes 
people think at least if this difference is for a reason or not and 
which way may be the right way to do it.

>> I am only reading what's in the comments and am trying to figure out how to correctly configure it to get a working tls server with the chain attached and allowing for client certificates.
> 
>    "correctly configure" means "it works".

Nope. Not with any security related service. "it works" does not mean 
"correctly configured".

I kind of makes me understand why you keep mentioning the "magic" in 
openssl. People don't spend the time to understand it and just guess and 
try and it works and they are happy. Of course, they never fully test it 
for all aspects what what should be accepted and what not.

The next project comes and picks up the code and does in the same way. 
It works. It's correctly configured. But who knows...

>    What doesn't work is reading the documentation, and then throwing your hands up in the air, and loudly proclaiming "it's garbage".   Which is quickly followed by "You guys need to fix it.  I refuse to contribute".

You never stop that, don't you? You really want to get rid of me.

>    Anyone with a little bit of self awareness should see how that is not going to be taken well.

But do you see that it doesn't help if you block off people who are 
trying to understand the details in order to be able to contribute? You 
don't want to understand the problem. You know how it works. There is no 
problem.

>> That's what I wrote in the issue, which you mostly ignore in your response.
> 
>    That's not true of course.  But I guess I've gotten used to that response.

Well, just take the statements I made and look at the statements to 
which you responded. Their is a discrepancy.

>> In the end, I have configured certificate_file with the server cert followed by the issuing ca chain and put all ca root and intermediate ca certs for client certificates into ca_file, so explicitly not doing what I "should" do.
> 
>    No.  The documentation doesn't say that configuration is forbidden.  It explicitly says it's allowed.

The comments say I "should" do otherwise. And everyone who is not 
sitting every day over the radius configuration will look at whats 
written in the comments. You know how it works. You don't have to read 
the comments.

But it is actually possible to describe those options clearly. For 
instance, if I read the ssl.conf for mod_ssl of httpd:

#   Server Certificate Chain:
#   Point SSLCertificateChainFile at a file containing the
#   concatenation of PEM encoded CA certificates which form the
#   certificate chain for the server certificate. Alternatively
#   the referenced file can be the same as SSLCertificateFile
#   when the CA certificates are directly appended to the server
#   certificate for convenience.
#SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt

#   Certificate Authority (CA):
#   Set the CA certificate verification path where to find CA
#   certificates for client authentication or alternatively one
#   huge file containing all of them (file must be PEM encoded)
#SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt

>> The texts in the comments is somewhat like a logical riddle to solve, you'll  have to try all possible combinations until you'll find one which doesn't end in a contradiction.
> 
>    Welcome to OpenSSL and TLS hell.  You're blaming us for OpenSSL weirdness.

I don't know about that, but adding confusing comments in the 
configuration files as guidance doesn't help.

I have never had any problems setting up a httpd tls server. No hell. 
Nothing weird. It's clear and straight forward. Even with client 
authentication set up...

>> Well, if the text is unclear and I don't know what the text really should be because it's unclear how everything is used exactly, I cannot give you a better text nor anything else "actionable". I can only point out, describe, explain the confusion.
> 
>    Substantial parts of your messages were little more than "the documentation is wrong / unclear".  Despite repeated attempts to get you to explain, you refused.  And instead of explaining, you started complaining about how "arrogant" I am.

I write long emails explaining it in length and you say I "refused"??

Seriously??

You are really not reading my mails.

You are really not even starting to try to understand what I write.

You want me to explain, I do explain, but you don't accept my 
explanation but instead say I refused to explain.

You just don't want my explanation.

That is just arrogant.

>    That's not an approach intended to make friends.

Well, right back at you.

>> At least for a lot of web servers running httpd or nginx, or postfix mail servers I never found myself in a situation that was unclear or was magically not working the way I expected it and how it was documented...
> 
>    Have you configured them with multiple CAs and multiple client certs?  I suspect not.

Yes. I did. It works. Nothing unclear about it. The TLS configuration 
works as expected. No "magic" or "hell".

> https://nginx.org/en/docs/http/configuring_https_servers.html
> 
>    Contains nothing about multiple CAs, and nothing about client certs.

You are taking that out of context. I didn't say that the nginx 
documentation is good. My statement above was in the reply to the 
"openssl" magic you claim. I haven't seen any "magic" or "hell" in 
either case. Nothing surprising or out of the ordinary.

>    So you're comparing apples to oranges here.  If you configure FreeRADIUS with one CA, then it's just as easy to configure as nginx.

No, you are just taking a statement regarding something else out of context.

>> It's you who is refusing and simply closed the issue before. It was a very clear sign to me that you are absolutely not interested in my feedback... It's not blame. You did close my issue. That's just what it is.
> 
>    As I've explained repeatedly, I'm interested in *good* feedback.  I have 25 years of proven history of accepting feedback from hundreds of people.  People who can clearly explain their issues and their requirements.

I am sorry, if my feedback is more complicated and thus not good enough 
for you. Though I don't know how to make it clearer when two statements 
kind of contradict each other.

>    The conclusion then is not that I don't want feedback, but (as I've said over and over) I want *good* feedback.  Yet somehow you've concluded that I'm the problem, and that I'm refusing your feedback because I'm arrogant.

Well, hundreds of lines of explanation are nothing worth for your and 
instead you tell me I "refused" an explanation.

I understand. You don't want my feedback. You don't even want to know my 
feedback.

>    All available evidence shows the opposite.
> 
>> It is what it is... I continue to contribute in the way I do, if you like it or not. You can complain about it or not. Or maybe I don't contribute anymore. There are a many other projects where they welcome my insight and contribution even if it is sometimes difficult to get a common understanding of things. And there is not this immediate hostility.
> 
>    I can't tell you how many times I've seen that response when I ask people to do something positive.  "Oh yeah?  You're mean!  I WOULD contribute, but I can't because you people are MEAN!"

Again, arrogance: obviously my previous contributions to others is 
obviously nothing worth in your eyes. I guess a real contribution is 
only one which ends up in a PR?

>    That response is *always* from people who don't contribute, and who don't intend to contribute.  It's like a poker "tell" for people who are more interested in complaining than making the world better.
> 
>    You're welcome to use FreeRADIUS.  You're welcome to contribute patches.  But I won't hold my breath.

O.K. Thanks for the clarification. Any worthy contribution in your eyes 
is only a patch.

You made it absolutely clear by now, it verbatim statements, that you 
don't want my contribution in any kind. Who am I to dare I might post 
something on this list to help someone else??

I am very sorry to have disturbed your reign on what is worthy of your 
attention and considered a worthy contribution.

You must really like to piss people off...

g