[
https://issues.apache.org/jira/browse/NIFI-14946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann resolved NIFI-14946.
-------------------------------------
Assignee: David Handermann
Resolution: Won't Fix
Thanks for describing the scenario and potential approach [~nicklarsennz].
The linked issue NIFI-14858 provides more extensive background on the basic
approach surrounding TLS verification handling. To summarize, the NiFi project
has a general approach of avoiding configuration options that introduce unclear
security boundaries. For this reason, the HandleHttpRequest and ListenHTTP
Processors follow the default settings for Jetty and TLS, without the ability
to disable SNI.
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, rather than introduce options that support TLS
using insecure settings.
> 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)
