[jira] [Commented] (NIFI-7786) Bring back Trusted Hostname property from InvokeHTTP processor
[ https://issues.apache.org/jira/browse/NIFI-7786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627440#comment-17627440 ] Liu Zheng commented on NIFI-7786: - To get around hostname is invalid, I had to manually extend a new InvokeHttp from the NAR level. I definitely know it's an untrusted certificate and doesn't follow subject alternative name matching, but it's just a test of the ip address. At the same time, the security measures are incredibly strict, especially for the subject alternative name. I can't rectify the whole system key for one tiny feature. This is not realistic. I've always felt that security risk is something to consider, but please leave the choice to the user, not the tool itself. > Bring back Trusted Hostname property from InvokeHTTP processor > -- > > Key: NIFI-7786 > URL: https://issues.apache.org/jira/browse/NIFI-7786 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.10.0 >Reporter: Kun Deng >Priority: Major > > Removing this option is a mistake. Just google how many people need this > option for various reasons. > It is an option so that by using it, people are willing to take the risks. > > Please bring back this option. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-7786) Bring back Trusted Hostname property from InvokeHTTP processor
[ https://issues.apache.org/jira/browse/NIFI-7786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17250884#comment-17250884 ] Noe commented on NIFI-7786: --- I have run into this issue and would like to see this option put back. As Nifi is used in various POCs it is advantageous to allow flexibility. "it can be imported into the local truststore explicitly" This is not the case. I ran into this problem after importing a Splunk default cert into the java/cacerts trustore that a Splunk server is using in development. A POC is not a reasonable time to harden an environment with standard security concerns. Can we please find a way to allow this functionality? > Bring back Trusted Hostname property from InvokeHTTP processor > -- > > Key: NIFI-7786 > URL: https://issues.apache.org/jira/browse/NIFI-7786 > Project: Apache NiFi > Issue Type: Bug >Reporter: Kun Deng >Priority: Major > > Removing this option is a mistake. Just google how many people need this > option for various reasons. > It is an option so that by using it, people are willing to take the risks. > > Please bring back this option. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-7786) Bring back Trusted Hostname property from InvokeHTTP processor
[
https://issues.apache.org/jira/browse/NIFI-7786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189375#comment-17189375
]
Andy LoPresto commented on NIFI-7786:
-
The comment on NIFI-6019 says that if the remote endpoint has an "invalid
certificate", you need to be able to bypass it. Can you elaborate on why the
certificate is invalid? If it is not signed by a trusted certificate authority,
it can be imported into the local truststore explicitly. If the certificate
identifies the wrong service hostname, is expired, or is revoked, it is a good
idea to reach out to the responsible team, inform them of the issues, and ask
for a resolution.
As Joe mentioned, there is a difficult balance between providing security and
flexibility to users. Providing bypasses (e.g. {{curl -k}}) tends to become
quickly abused and misunderstood, and opens a number of visible/invisible
vulnerabilities that not all users are aware of. Because of the broad audience
for NiFi, there is rarely a single "correct" solution.
An admin override setting explicitly acknowledging the unsafe decision might be
the best path forward, but we actually have not received much pushback since
this decision was enacted (we received a number of issues before on the mailing
lists). If this is a blocker for you, you might want to also investigate
workarounds like {{ExecuteProcess}} using {{curl -k}} or forking the
project/building & deploying a custom processor using the previous version.
> Bring back Trusted Hostname property from InvokeHTTP processor
> --
>
> Key: NIFI-7786
> URL: https://issues.apache.org/jira/browse/NIFI-7786
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: Kun Deng
>Priority: Major
>
> Removing this option is a mistake. Just google how many people need this
> option for various reasons.
> It is an option so that by using it, people are willing to take the risks.
>
> Please bring back this option.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NIFI-7786) Bring back Trusted Hostname property from InvokeHTTP processor
[ https://issues.apache.org/jira/browse/NIFI-7786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189351#comment-17189351 ] Joe Witt commented on NIFI-7786: [~kundeng] It is important to provide the context for your request. I had to search and have now linked for what you were talking about. Your statement in the above linked comment suggests you really liked the ability to disable verification. We understand and this is indeed why it was there. But we also found users not realizing how TLS works and tweaking that setting finding it suddenly working only to not realize they were insecure. Who does that fall back to? That comes back to us. The notion of enforcing security vs giving options, etc... this is a tricky balance frankly. The only real path we've found that helps is to let users turn on a property in something like "enable.unsafe.security.related.options" such that if a user turns that on then we're free to support a range of options that while flexible are not safe In short this isn't an easy line to walk. I get your point from a user point of view and I hope you appreciate the challenge we face in providing good software that favors security 'correctly'. I'm not in favor of this property, or others like it, returning to the system with forcing users to explicitly say they're intentionally enabling features which allow non secure practices. > Bring back Trusted Hostname property from InvokeHTTP processor > -- > > Key: NIFI-7786 > URL: https://issues.apache.org/jira/browse/NIFI-7786 > Project: Apache NiFi > Issue Type: Bug >Reporter: Kun Deng >Priority: Major > > Removing this option is a mistake. Just google how many people need this > option for various reasons. > It is an option so that by using it, people are willing to take the risks. > > Please bring back this option. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-7786) Bring back Trusted Hostname property from InvokeHTTP processor
[ https://issues.apache.org/jira/browse/NIFI-7786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189347#comment-17189347 ] Joe Witt commented on NIFI-7786: https://issues.apache.org/jira/browse/NIFI-6019?focusedCommentId=17189312=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17189312 > Bring back Trusted Hostname property from InvokeHTTP processor > -- > > Key: NIFI-7786 > URL: https://issues.apache.org/jira/browse/NIFI-7786 > Project: Apache NiFi > Issue Type: Bug >Reporter: Kun Deng >Priority: Major > > Removing this option is a mistake. Just google how many people need this > option for various reasons. > It is an option so that by using it, people are willing to take the risks. > > Please bring back this option. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-7786) Bring back Trusted Hostname property from InvokeHTTP processor
[ https://issues.apache.org/jira/browse/NIFI-7786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189345#comment-17189345 ] Joe Witt commented on NIFI-7786: https://issues.apache.org/jira/browse/NIFI-6019 > Bring back Trusted Hostname property from InvokeHTTP processor > -- > > Key: NIFI-7786 > URL: https://issues.apache.org/jira/browse/NIFI-7786 > Project: Apache NiFi > Issue Type: Bug >Reporter: Kun Deng >Priority: Major > > Removing this option is a mistake. Just google how many people need this > option for various reasons. > It is an option so that by using it, people are willing to take the risks. > > Please bring back this option. -- This message was sent by Atlassian Jira (v8.3.4#803005)
