[
https://issues.apache.org/jira/browse/NIFI-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17210544#comment-17210544
]
David Handermann commented on NIFI-1364:
----------------------------------------
Reviewing the current PR, calling Security.setProperty() to enable OCSP and set
the Responder URL impacts the entire JVM, which seems problematic. Whereas the
current BouncyCastle implementation performs verification for requests to the
NiFi system, calling Security.setProperty() would also impact other TLS
communications, such as instances of ListenHTTP, which might be configured with
a different X.509 certificate.
If the goal is to enable OCSP at the JVM level, it seems like a better approach
would be to provide a commented Java Security properties file that could be
referenced in bootstrap.conf using "-Djava.security.properties" to set
[Client-Driven
OCSP|https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/ocsp.html#ocsp-pki]
properties. The same document also lists the System properties that can be
set for [Server-Side OCSP
Stapling|https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/ocsp.html#server-side-properties],
which has some benefits over the Client-Driven approach.
Keeping the current OCSP implementation provides more granular control over
access to NiFi itself versus data transport access through other TLS-based
communications. If the decision is to retain the current BouncyCastle
implementation, it could be worth implementing customizable OCSP support for
instances of the SSLContextService.
> 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: Nathan Gough
> Priority: Major
> Labels: certificate, ocsp, security
> Time Spent: 2h
> Remaining Estimate: 0h
>
> 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
(v8.3.4#803005)
