FreeRADIUS 3 package will not start

PFbest

What's in /usr/local/etc/raddb/clients.conf? (line 20, but post some context as well).

mmmm, Interesting

line 20 is this: secret = A<103.,c-!:@=1;d,f<@># <dkg1nc-1 It must be improper character escape bug I assume? Since it's working under V2
;)</dkg1nc-1

PFbest

Fixed secret, now I have new error with radiusd -X

tls: Failed reading Trusted root CA list "/usr/local/etc/raddb/certs/ca_cert.pem"
tls: error:0906D066:PEM routines:PEM_read_bio:bad end line
tls: error:0B084009:x509 certificate routines:X509_load_cert_crl_file:PEM lib
rlm_eap_tls: Failed initializing SSL context
rlm_eap (EAP): Failed to initialise rlm_eap_tls
/usr/local/etc/raddb/mods-enabled/eap[2]: Instantiation failed for module "eap"

:o

doktornotor

No idea what you have there in ca_cert.pem. It's supposed to end with


-----END CERTIFICATE-----

PFbest

@doktornotor:

No idea what you have there in ca_cert.pem. It's supposed to end with
-----END CERTIFICATE-----

Weird, my CA was the default one, generated when pfsense was installed

PFbest

Interesting.

After dig into the CA.

I found that the CA file was cut off at the end, like several lines are missing.

After I copied back the complete CA content, everything rocks again. ;D ;D

That's something new to know I guess.

Thanks very much guys!

Cheers!!!

doktornotor

OK… No idea how the CA file got corrupted, the package just uses whatever is saved as a selected CA certificate in config.xml.

PFbest

@doktornotor:

OK… No idea how the CA file got corrupted, the package just uses whatever is saved as a selected CA certificate in config.xml.

I know, it's weird.
I don't even know when it gets corrupted.
At least now I know there is one more thing need to be aware of when freeradius goes wrong.

;)

doktornotor

One more thing - can you test the shared secret like this?

'A<103.,c-!:@=1;d,f<@># <dkg1nc-1' (Save and check whether RADIUS is still running.)</dkg1nc-1'

PFbest

@doktornotor:

One more thing - can you test the shared secret like this?

'A<103.,c-!:@=1;d,f<@># <dkg1nc-1' (Save and check whether RADIUS is still running.)</dkg1nc-1'

Like put exactly 'A<103.,c-!:@=1;d,f<@>#

doktornotor

Yes.

PFbest

@doktornotor:

Yes.

Errrr, guess it won't work?
Cause it's over 31 characters :o

doktornotor

It should still stay 31 characters, just avoid the misparsing issues. See man unlang regarding the single quotes. The single quotes shouldn't count as part of the secret.

PFbest

@doktornotor:

It should still stay 31 characters, just avoid the misparsing issues. See man unlang regarding the single quotes. The single quotes shouldn't count as part of the secret.

Ummmmmm
It returns error as in image

nas.png_thumb

doktornotor

Eh, well… edit this line to 33. I just wanted you to test whether it stops breaking the config, that's all.

PFbest

@doktornotor:

Eh, well… edit this line to 33. I just wanted you to test whether it stops breaking the config, that's all.

Cool, tested.
Results are:

doktornotor

Yes, as said, the secret does not really change. I'll do a PR to add single quotes around the secret automatically so that you can input it without quotes in both the AP and pfSense.

https://redmine.pfsense.org/issues/7836
https://github.com/pfsense/FreeBSD-ports/pull/415

PiBa

Thanks doktornotor 8)
One question though, can a single quote (or backslash) be part of the secret? And if so, should it also be escaped.?.
Found this http://networkradius.com/doc/3.0.10/raddb/syntax/data_string.html but not sure its about the exact same software.

Example
'a string with spaces'
'a string with \'quotes\' in it'
'a string with a backslash \\ in it'

Um ok, reading your pullrequest while writing this i realize your asking the enduser to do this, but then the check for 31 characters should perhaps also allow more characters.?. Wouldnt it be easier to let the code writing the config file do the proper escaping?

doktornotor

There are tons of places in pfSense where the code won't work as expected when doing things like putting various UTF-8 accented chars, or even multibyte characters into passwords, secrets and other settings since it either breaks config.xml or strlen() and other non mb_ prefixed functions don't handle this.

https://redmine.pfsense.org/issues/7186
https://redmine.pfsense.org/issues/7423
https://redmine.pfsense.org/issues/7623

The field in freeradiusclients.xml is not base64-encoded because it wasn't possible with XML and pasword-type field. Now, when you attempt to use some functions to automatically escape/replace things with those non-encoded strings, you run into things like this one. When you switch the field to use base64, you need to write code to upgrade the config automatically on installing the next package version.

Afraid someone else will need to do the job since I frankly think that people that insist on shooting themselves in the foot need to pick up the pieces. (I recall a couple of threads here where people were complaining that putting a carriage return character in password makes their life miserable with password prompts… ::))

doktornotor

And one final thing - the idea to "let the code writing the config file do the proper escaping" is very cool until you run into a genius who invents a secret like f#$k'1t and you don't know whether he meant to escape the ' or literally use ' :-X

PiBa

Ok the ' and \ aren't 'very special' like some of the other examples you provide, but i get the point ;D
Having a carriage return in a password must be very secure i havn't thought about using that in any my passwords sofar ;).

imho in general escaping in config files should be done by 'the software', and if a genius did it manually, then i suppose thats to bad for them when pfSense gets 'fixed'. Cant expect the enduser to know/lookup every escape sequence for each piece of software used by pfSense. So your patch certainly helps make that clear for this field. But i guess my point is made :)

Lets wait for someone to run into it and then perhaps take another look.