[
https://issues.apache.org/jira/browse/NIFI-14946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18019380#comment-18019380
]
David Handermann edited comment on NIFI-14946 at 9/10/25 3:26 PM:
------------------------------------------------------------------
Thanks for the reply.
Support for HTTP versus HTTPS provides a clear distinction between no security
and encryption with verification. Introducing options to disable some aspects
of TLS verification, such as SNI checking changes the scope of security to
encryption with less verification. Some may understand this distinction, but it
is often unclear, and can easily become of matter of simply changing properties
to make things work.
It is true that there is a certain level of responsibility that is inherent in
installing and configuring a system such as NiFi, and the project Security
Model describes some of those expectations. The challenge from a maintenance
perspective is taking on the responsibility to support options that are more
potentially problematic. The InvokeHTTP Processor, for instance, used to have a
configuration property that supported bypassing hostname verification, but this
was removed several years ago. Thus the current general strategy of requiring
such special cases to be handled through custom components maintained outside
of the project itself.
was (Author: exceptionfactory):
Thanks for the reply.
Support for HTTP versus HTTPS provides a clear distinction between no security
and encryption with verification. Introducing options to disable some aspects
of TLS verification, such as SNI checking changes the scope of security to
encryption with less verification. Some may understand this distinction, but is
often unclear, and can easily become of matter of simply changing properties to
make things work.
It is true that their is a certain level of responsibility that is inherent in
installing and configuring a system such as NiFi, and the project Security
Model describes some of those expectations. The challenge from a maintenance
perspective is taking on the responsibility to support options that are more
potentially problematic. The InvokeHTTP Processor, for instance, used to have a
configuration property that supported bypassing hostname verification, but this
was removed several years ago. Thus the current general strategy of requiring
such special cases to be handled through custom components maintained outside
of the project itself.
> 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)
