TLS. CRLs are downloaded only for local certificates

[serega911]

Hi,

Trust chains:

CLIENT_CERT -> CA       -> ROOT_CA
SERVER_CERT -> OTHER_CA -> ROOT_CA

All certificates except ROOT_CA have an "id-ce-cRLDistributionPoints" extension.

Configuration:
CA, OTHER_CA, and ROOT_CA are added to the certificate-bag in the ietf-truststore module.
SERVER_CERT and corresponding keys, etc. are also configured accordingly.

Observation:
When mutual TLS session is established, CRLs are downloaded for SERVER_CERT, OTHER_CA and CA, but not for certificates received from the peer:
https://github.com/CESNET/libnetconf2/blob/284ee667445c34402ebbe83c5b38344d6283d6ce/src/session.c#L1833

Then, because there are some CRLs downloaded for local certificares, openssl is configured to enable CRL check: https://github.com/CESNET/libnetconf2/blob/284ee667445c34402ebbe83c5b38344d6283d6ce/src/session_openssl.c#L906

CRL check now is enabled for all certificates. As a result, CRL check fails for the CLIENT_CERT (which also has CRL distribution point field), because its CRL is never downloaded. In the debug output it looks like:

[INF]: LN: Cert verify: fail (unable to get certificate CRL).
[ERR]: LN: Client certificate error (unable to get certificate CRL).
[ERR]: LN: TLS accept failed (certificate verify failed).

Expected behavior:
If CRL extension is present in certificate, it should be downloaded for both local and peer certificates.

Thanks!

[Roytak]

Hi, I submitted a fix for this, in CESNET/libnetconf2#611 . Could you try out the devel branch to see if it fixes your use case, once it's merged? Would be very appreciated, thank you.

[serega911]

Hi!

I have performed some testing, and it seems to be working. Thank you very much!

The only thing I noticed is that it downloads same CRLs several times (the same URI might be present in different certificates).

[INF]: LN: Downloading CRL from "http://localhost:8080/operator-certs/inter2-ca.crl".
[INF]: LN: Downloading CRL from "http://localhost:8080/operator-certs/root-ca.crl".
[INF]: LN: Downloading CRL from "http://localhost:8080/operator-certs/root-ca.crl".
[INF]: LN: Downloading CRL from "http://localhost:8080/operator-certs/inter-ca.crl".
[INF]: LN: Downloading CRL from "http://localhost:8080/operator-certs/root-ca.crl".

This might be a problem when there is no route to the host defined in the URI. It is possible that certificate has several URIs. For example, one with ipv4 and one with ipv6. If there is no ipv4 route to the host, CURL will spend extra time for each unreachable URI (up to several seconds for each).

[INF]: LN: Downloading CRL from "http://<ipv4:port>/path".
[ERR]: LN: Downloading CRL from "http://<ipv4:port>/path" failed (Failed to connect to **** port **** after 2558 ms: No route to host).
[WRN]: LN: Failed to fetch CRL from "http://<ipv4:port>/path".
[INF]: LN: Downloading CRL from "http://<ipv6:port>/path".                             <- OK

In total I have had 10 seconds delay which caused client to close the connection. I ended up with a patch to set a timeout for CURL.

diff --git a/src/session.c b/src/session.c
index 1017618..00328e4 100644
--- a/src/session.c
+++ b/src/session.c
@@ -1703,6 +1703,16 @@ nc_session_curl_init(CURL **handle, struct nc_curl_data *data)
         return 1;
     }

+    if (curl_easy_setopt(*handle, CURLOPT_CONNECTTIMEOUT, 1)) {
+        ERR(NULL, "Setting curl connection timeout failed.");
+        return 1;
+    }
+
+    if (curl_easy_setopt(*handle, CURLOPT_NOSIGNAL, 1)) {
+        ERR(NULL, "Setting CURLOPT_NOSIGNAL failed.");
+        return 1;
+    }
+
     if (curl_easy_setopt(*handle, CURLOPT_WRITEFUNCTION, nc_session_curl_cb)) {
         ERR(NULL, "Setting curl callback failed.");
         return 1;

-Sergii

[Roytak]

Hi, thanks for trying it out! I also noticed the extra downloads from the same URIs. Prepared changes that should avoid those extra downloads. I also added those curl opts to the project, the timeout is an internal macro though if you want to tweak that. If you'd try it out again once it's merged, would be very appreciated, thank you.

[serega911]

Hi,

I tested it. It looks good. I have tried clients for both trust chains. In the initial description I posted

CLIENT_CERT -> CA       -> ROOT_CA
SERVER_CERT -> OTHER_CA -> ROOT_CA

It was just an example. My real test chains are:

SERVER_CERT -> ca -> inter-ca -> root-ca
CLIENT_CERT -> ca -> inter-ca -> root-ca
CLIENT2_CERT -> inter2-ca -> root-ca

What I see in logs now is.
If client uses CLIENT_CERT:

[INF]: LN: Downloading CRL from "http://localhost:8080/operator-certs/ca.crl".
[INF]: LN: Downloading CRL from "http://localhost:8080/operator-certs/root-ca.crl".
[INF]: LN: Downloading CRL from "http://localhost:8080/operator-certs/inter-ca.crl".

If client uses CLIENT2_CERT:

[INF]: LN: Downloading CRL from "http://localhost:8080/operator-certs/inter2-ca.crl".
[INF]: LN: Downloading CRL from "http://localhost:8080/operator-certs/root-ca.crl".
[INF]: LN: Downloading CRL from "http://localhost:8080/operator-certs/inter-ca.crl".

I'm not sure why ca.crl is not downloaded, but connection is established.
ietf-truststore is configured to store root-ca, inter-ca, inter2-ca and ca certificates

Have to mention that I'm cherry-picking your commits to my local branch which is based on commit 61fbe731908809f88a187f223d43718479a7e0da (tag: v3.7.10). I had to resolve some conflicts.

Thank you so much for fixing it!