[jira] [Comment Edited] (NIFI-1364) Audit OCSP certificate validation

["Matt Gilman (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/NIFI-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15767342#comment-15767342 ] 

Matt Gilman edited comment on NIFI-1364 at 12/21/16 3:40 PM:
-------------------------------------------------------------

Following a conversation on the mailing list [1] I did some testing of certificate revocation specifically for clients of the REST API and the cluster protocol. I was able to successfully use Java's built-in OCSP verification for both. We should consider the following for this JIRA:

1) Remove the legacy OCSP verification
2) Support configuration of Java's built-in OCSP verification. Specifically, when building an SSLContext I believe we need to configure the TrustManagerFactory as below. Though I believe this is only applicable when TrustManagerFactory.getDefaultAlgorithm() is PKIX. Probably makes sense to revert to the current implementation when it is not:

{code}
PKIXBuilderParameters pbParams = new PKIXBuilderParameters(trustStore, new X509CertSelector());

        pbParams.setRevocationEnabled(true);

        Security.setProperty("ocsp.enable","true");

        TrustManagerFactory trustManagerFactory = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
        trustManagerFactory.init(new CertPathTrustManagerParameters(pbParams));
{code}

There are a couple places (cluster protocol, site to site, etc) where these changes would be required as mentioned in the JIRA description. We should consider consolidating these during this effort. Additionally, there are other OCSP features that we should consider offering support for [2].

One thing I noted during my testing that is likely a follow on JIRA. When a node in the cluster with a valid certificate was chosen as the coordinator the behavior was as expected. Nodes with valid certificates joined. Nodes with revoked certificates could not. However, if a node with a revoked certificate was chosen as the coordinator, no nodes could join the cluster.

[1] https://lists.apache.org/thread.html/fe6d34c375a459d3aaf997e9350f3bbba141d562a733dfd496697ccd@%3Cdev.nifi.apache.org%3E
[2] http://docs.oracle.com/javase/6/docs/technotes/guides/security/certpath/CertPathProgGuide.html#AppC


was (Author: mcgilman):
Following a conversation on the mailing list [1] I did some testing of certificate revocation specifically for clients of the REST API and the cluster protocol. I was able to successfully use Java's built-in OCSP verification for both. We should consider the following for this JIRA:

1) Remove the legacy OCSP verification
2) Support configuration of Java's built-in OCSP verification. Specifically, when building an SSLContext I believe we need to configure the TrustManagerFactory as below. Though I believe this is only applicable when TrustManagerFactory.getDefaultAlgorithm() is PKIX. Probably makes sense to revert to the current implementation when it is not:

{code}
PKIXBuilderParameters pbParams = new PKIXBuilderParameters(trustStore, new X509CertSelector());

        // Make sure revocation checking is enabled
        pbParams.setRevocationEnabled(true);

        // Enable On-Line Certificate Status Protocol (OCSP) support
        Security.setProperty("ocsp.enable","true");

        TrustManagerFactory trustManagerFactory = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
        trustManagerFactory.init(new CertPathTrustManagerParameters(pbParams));
{code}

There are a couple places (cluster protocol, site to site, etc) where these changes would be required as mentioned in the JIRA description. We should consider consolidating these during this effort. Additionally, there are other OCSP features that we should consider offering support for [2].

One thing I noted during my testing that is likely a follow on JIRA. When a node in the cluster with a valid certificate was chosen as the coordinator the behavior was as expected. Nodes with valid certificates joined. Nodes with revoked certificates could not. However, if a node with a revoked certificate was chosen as the coordinator, no nodes could join the cluster.

[1] https://lists.apache.org/thread.html/fe6d34c375a459d3aaf997e9350f3bbba141d562a733dfd496697ccd@%3Cdev.nifi.apache.org%3E
[2] http://docs.oracle.com/javase/6/docs/technotes/guides/security/certpath/CertPathProgGuide.html#AppC

> Audit OCSP certificate validation
> ---------------------------------
>
>                 Key: NIFI-1364
>                 URL: https://issues.apache.org/jira/browse/NIFI-1364
>             Project: Apache NiFi
>          Issue Type: Task
>          Components: Core Framework
>    Affects Versions: 0.4.1
>            Reporter: Andy LoPresto
>            Assignee: Andy LoPresto
>              Labels: certificate, ocsp, security
>
> While upgrading the version of BouncyCastle libraries used, I had to re-write the OCSP certificate validation code because BC split the PKIX code into a separate module and renamed many classes & methods. During this re-write, I made the code compile using the new logic, but I am unsure that OCSP validation needs to occur outside of the SSL/TLS negotiation, or that the current mechanism is correct. 
> Questions:
> * Can we use Java's built-in OCSP validation? [1][2]
> * Is the current mechanism correct, where a local cache is used with custom internal classes representing OCSP requests and statuses, and it queries a pre-specified OCSP responder as opposed to the per-certificate OCSP responder listed in each certificate's Authority Information Access OCSP URI [3]? I think this design decision stems from a legacy environment which may not apply to current use cases. 
> More information: [4]
> [1] https://blogs.oracle.com/xuelei/entry/enable_ocsp_checking
> [2] https://stackoverflow.com/questions/8506661/check-x509-certificate-revocation-status-in-spring-security-before-authenticatin
> [3] https://blog.ivanristic.com/2014/02/checking-ocsp-revocation-using-openssl.html
> [4] https://raymii.org/s/articles/OpenSSL_Manually_Verify_a_certificate_against_an_OCSP.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)