FR 3.0.11, RadSec, validation via an external command
Hi, May I ask for your comment on how to fix/deal with two issues I've experienced with FR 3.0.11? Required funcionality: RadSec TLS peer/client certificate to be validated by an external command. AFAIU certificate validation by external command (i.e. tls configuration stanza verify) requires ocsp to be enabled, accordig to FR 3.0.11 documentation. Issue 1 (OCSP checks fail for a RadSec client): FR 3.0.11 is passing a null-valued cert. store pointer over to openssl's function OCSP_basic_verify() resulting in segfault within openssl's libcrypto. Prior FR code attempt to fill ocsp_store pointer via SSL_get_ex_data(ssl, FR_TLS_EX_INDEX_STORE) call is of no help as FR 3.0.11 code path doesn't seem to invoke a corresponding SSL_set_ex_data() function call for a RadSec client TLS connection. I'm not sure what a correct fix should look like. I've replaced the function call: ocsp_store = (X509_STORE *)SSL_get_ex_data(ssl, FR_TLS_EX_INDEX_STORE); by a reference: ocsp_store = conf->ocsp_store; for purpose of a local test as conf->ocsp_store is already initialized at that point in code. Issue 2 (validation via external command blocked by if clause): Even if ocsp check is enabled, there seems to be little chance for external validation to kick in. Contrary to FR 3.0.11 documentation, the code requires two contending conditions to be satisfied at once. These conditions prevent external validation command from beeing called in case prior ocsp check returns OK. Local interim/test fix for both issues is attached. Thanks for your comments. Kind regards, Martin
On Sep 21, 2016, at 5:44 AM, Martin Stanislav <ms@uakom.sk> wrote:
May I ask for your comment on how to fix/deal with two issues I've experienced with FR 3.0.11?
Required funcionality: RadSec TLS peer/client certificate to be validated by an external command.
AFAIU certificate validation by external command (i.e. tls configuration stanza verify) requires ocsp to be enabled, accordig to FR 3.0.11 documentation.
# If OCSP checking is enabled, and the OCSP checks fail, # the verify section is skipped. You should be able to run the external command without OCSP.
Issue 1 (OCSP checks fail for a RadSec client):
FR 3.0.11 is passing a null-valued cert. store pointer over to openssl's function OCSP_basic_verify() resulting in segfault within openssl's libcrypto. Prior FR code attempt to fill ocsp_store pointer via SSL_get_ex_data(ssl, FR_TLS_EX_INDEX_STORE) call is of no help as FR 3.0.11 code path doesn't seem to invoke a corresponding SSL_set_ex_data() function call for a RadSec client TLS connection.
OK, that makes sense. I'll push a fix.
I'm not sure what a correct fix should look like. I've replaced the function call: ocsp_store = (X509_STORE *)SSL_get_ex_data(ssl, FR_TLS_EX_INDEX_STORE); by a reference: ocsp_store = conf->ocsp_store; for purpose of a local test as conf->ocsp_store is already initialized at that point in code.
That makes sense.
Issue 2 (validation via external command blocked by if clause):
Even if ocsp check is enabled, there seems to be little chance for external validation to kick in. Contrary to FR 3.0.11 documentation, the code requires two contending conditions to be satisfied at once. These conditions prevent external validation command from beeing called in case prior ocsp check returns OK.
The problem is that your patch completely removes all of the logic about checking the OCSP status. I'll push a fix which matches the comments in the code, and the documentation. Alan DeKok.
On Wed, Sep 21, 2016 at 09:45:08AM -0400, Alan DeKok wrote:
# If OCSP checking is enabled, and the OCSP checks fail, # the verify section is skipped.
You should be able to run the external command without OCSP.
That makes sense. But as I understand the code, it doesn't allow for external command without OCSP enabled. I think I even tested it. Also, the following two lines in verify stanza (eap module) don't make things clear enough: # If the OCSP checks succeed, the verify section # is run to allow additional checks.
Issue 1 (OCSP checks fail for a RadSec client):
OK, that makes sense. I'll push a fix.
Thanks for pushing the fix.
Issue 2 (validation via external command blocked by if clause):
The problem is that your patch completely removes all of the logic about checking the OCSP status.
I admit I've oversimlified a bit.
I'll push a fix which matches the comments in the code, and the documentation.
I see the patched code, commit c88614354f80bec0e0e777338e170474f2242212. However, the documentation says: * If OCSP returns skipped (2), we run the verify command, unless * conf->verify_skip_if_ocsp_ok is true. That demands one more modification to fit exactly: - ((my_ok == OCSP_STATUS_SKIPPED) && conf->verify_skip_if_ocsp_ok)) + ((my_ok == OCSP_STATUS_SKIPPED) && !conf->verify_skip_if_ocsp_ok)) The code will get even more convoluted, should it introduce a possibility to run an external command (verify) when ocsp is disabled. See attached nasty diff. Thanks for your comments and care. Martin
On Sep 23, 2016, at 9:32 AM, Martin Stanislav <ms@uakom.sk> wrote:
On Wed, Sep 21, 2016 at 09:45:08AM -0400, Alan DeKok wrote:
# If OCSP checking is enabled, and the OCSP checks fail, # the verify section is skipped.
You should be able to run the external command without OCSP.
That makes sense. But as I understand the code, it doesn't allow for external command without OCSP enabled. I think I even tested it.
Yes. I've cleaned up the code, and added comments to the EAP module configuration, and to the release notes. Alan DeKok.
participants (2)
-
Alan DeKok -
Martin Stanislav