[
https://issues.apache.org/jira/browse/NIFI-14946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18019377#comment-18019377
]
Nick commented on NIFI-14946:
-----------------------------
> To summarize, the NiFi project has a general approach of avoiding
> configuration options that introduce unclear security boundaries
I think this is a great stance for defaults, but I think it is too harsh to
"not allow overrides" (especially in a service which can be maintained by
Admins) when HTTP is allowed as an option (which I would argue also has unclear
security boundaries).
> If a particular organization allows more lenient client certificate
> verification and TLS handshaking, the best option is to maintain a custom
> version of these components
On the surface, this sounds reasonable, but it then becomes a discoverability
issue when you extrapolate across many organizations who would like these
overrides.
Anyway, thanks for your quick response. I will read up on how to make a custom
component for curiosity's sake.
> Override Jetty Settings in the HandleHttpRequest processor
> ----------------------------------------------------------
>
> Key: NIFI-14946
> URL: https://issues.apache.org/jira/browse/NIFI-14946
> Project: Apache NiFi
> Issue Type: Improvement
> Reporter: Nick
> Assignee: David Handermann
> Priority: Major
>
> Jetty currently enforces a check that the `Host` header in the HTTP request
> is a valid subject in the Certificate (and if not, it fails with an `Invalid
> SNI` error - which is not correctly worked but it is done in the same part of
> the code that does check that the SNI server_name matches a valid SAN).
> There are cases where (in an organization) it is acceptable for the client to
> deal with the issue of TLS trust, and allow the server (created by
> HandleHttpRequest) to serve, no matter the hostname.
> It would be nice to be able to configure some of the settings of the
> [SecureRequestCustomizer|https://javadoc.jetty.org/jetty-12/org/eclipse/jetty/server/SecureRequestCustomizer.html]
> This could be done by either:
> * adding some explicit configurable properties to the HandleHttpRequest
> processor, or
> * making a new Service for configuring the SecureRequestCustomizer
> I think the latter option is ideal, as it could be reused by another other
> processor that creates a Jetty server.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
