From issues-return-92616-archive-asf-public=cust-asf.ponee.io@nifi.apache.org Fri Feb 21 18:21:02 2020 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 3B0E9180657 for ; Fri, 21 Feb 2020 19:21:02 +0100 (CET) Received: (qmail 18582 invoked by uid 500); 21 Feb 2020 18:21:01 -0000 Mailing-List: contact issues-help@nifi.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@nifi.apache.org Delivered-To: mailing list issues@nifi.apache.org Received: (qmail 18571 invoked by uid 99); 21 Feb 2020 18:21:01 -0000 Received: from mailrelay1-us-west.apache.org (HELO mailrelay1-us-west.apache.org) (209.188.14.139) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 21 Feb 2020 18:21:01 +0000 Received: from jira-he-de.apache.org (static.172.67.40.188.clients.your-server.de [188.40.67.172]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 9906CE0EAA for ; Fri, 21 Feb 2020 18:21:00 +0000 (UTC) Received: from jira-he-de.apache.org (localhost.localdomain [127.0.0.1]) by jira-he-de.apache.org (ASF Mail Server at jira-he-de.apache.org) with ESMTP id 17BFB7800CE for ; Fri, 21 Feb 2020 18:21:00 +0000 (UTC) Date: Fri, 21 Feb 2020 18:21:00 +0000 (UTC) From: "Andy LoPresto (Jira)" To: issues@nifi.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (NIFI-7064) Support 2-way SSL by InvokeHTTP processor MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/NIFI-7064?page=3Dcom.atlassian.= jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D17042= 089#comment-17042089 ]=20 Andy LoPresto commented on NIFI-7064: ------------------------------------- Dmitry,=20 Thanks for following up, but I am still confused by your scenario. You say = that NiFi is acting as a server and does not have a DNS hostname, only an I= P address, so you put a SAN entry for that IP into the NiFi certificate. Th= is makes sense so far.=20 Then you say that because the clients are greenfield development, they also= do not have a DNS hostname. They receive an assigned IP address dynamicall= y, and because this can change, it cannot be added to the client certificat= e as a SAN entry. I also understand this point but I am not sure how you wi= ll issue certificates which comply with RFC 6125 because of this obstacle.= =20 The part that is confusing is here: if NiFi is the server and the clients a= re external, how are you using {{InvokeHTTP}}? That processor is used to in= itiate a connection _from_ NiFi _to_ an external system. By definition then= , NiFi is the _client_.=20 I don't think we want to introduce a mechanism into NiFi which allows bypas= s of the TLS hostname verification by overloading it with a custom process,= especially one that defaults to host validation false. This previously exi= sted in some other processors and has been deprecated and/or removed. This = may be a scenario where {{ExecuteScript}} or a custom processor is needed t= o dynamically negotiate the handshake outside of the normal RFC 6125 proces= s.=20 > Support 2-way SSL by InvokeHTTP processor > ----------------------------------------- > > Key: NIFI-7064 > URL: https://issues.apache.org/jira/browse/NIFI-7064 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework, Security > Affects Versions: 1.10.0 > Reporter: Dmitry Mashkov > Priority: Major > Labels: features, patch, ready-to-commit, security > Attachments: InvokeHTTP_2-way_SSL_hostvalidation_support.patch > > > HandleHTTPRequest processor as server, supports 2Way SSL( ie client authe= ntication). InvokeHTTP processor as client, unfortunately not. I would like= provide my patch for InvokeHTTP processor.See attach. > Here some comments for code. > I added Client.Auth methods > I added hostname validator. > Due to original code base and chosen HTTP client, I changed OkHttpClient = reference to OkHttpClient.Builder for host validation handler. I have not w= ay to support EL in properties and pass them to handler from setupto trigge= r via context. > {code:java} > AtomicReference okHttpClientBuilderAtomicReferenc{c= ode} > Most hard and long operations done before trigger, while scheduler starts= , building client is relatively lightweight. > Some comments about host validator, reasons to do this. > My case is build RESTful services with 2-way SSL authentication by IP. Re= mote client can be a servers at same time as a clients, like mutual communi= cation, but no domains, only IPs in green field. More over, clients can cha= nge dynamically their IP due to selected channel, LAN or Cellular, here is = not way to provide SAN to certificate at configuration. Now you can provide= dynamically via EL/param IP addresses to check hostname for client authent= ication. > =C2=A0 > PS. It's not clear code, why processor build SSLContext in SSL Context Co= ntrolller, but not use it anyhow? This is strange and unclear, possibly, he= re we can reduce the code. > PPS. It not clear, how to build tests for this case. > =C2=A0 > =C2=A0 > Sincerely, > Dmitry. -- This message was sent by Atlassian Jira (v8.3.4#803005)