nifi-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy LoPresto (Jira)" <j...@apache.org>
Subject [jira] [Commented] (NIFI-7064) Support 2-way SSL by InvokeHTTP processor
Date Fri, 21 Feb 2020 18:21:00 GMT

    [ https://issues.apache.org/jira/browse/NIFI-7064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17042089#comment-17042089
] 

Andy LoPresto commented on NIFI-7064:
-------------------------------------

Dmitry, 

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 IP address, so you put a SAN entry for
that IP into the NiFi certificate. This makes sense so far. 

Then you say that because the clients are greenfield development, they also do not have a
DNS hostname. They receive an assigned IP address dynamically, and because this can change,
it cannot be added to the client certificate as a SAN entry. I also understand this point
but I am not sure how you will issue certificates which comply with RFC 6125 because of this
obstacle. 

The part that is confusing is here: if NiFi is the server and the clients are external, how
are you using {{InvokeHTTP}}? That processor is used to initiate a connection _from_ NiFi
_to_ an external system. By definition then, NiFi is the _client_. 

I don't think we want to introduce a mechanism into NiFi which allows bypass of the TLS hostname
verification by overloading it with a custom process, especially one that defaults to host
validation false. This previously existed in some other processors and has been deprecated
and/or removed. This may be a scenario where {{ExecuteScript}} or a custom processor is needed
to dynamically negotiate the handshake outside of the normal RFC 6125 process. 


> 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 authentication).
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 way to support EL in properties
and pass them to handler from setupto trigger via context.
> {code:java}
> AtomicReference<OkHttpClient.Builder> okHttpClientBuilderAtomicReferenc{code}
> 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. Remote client
can be a servers at same time as a clients, like mutual communication, but no domains, only
IPs in green field. More over, clients can change 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 authentication.
>  
> PS. It's not clear code, why processor build SSLContext in SSL Context Controlller, but
not use it anyhow? This is strange and unclear, possibly, here we can reduce the code.
> PPS. It not clear, how to build tests for this case.
>  
>  
> Sincerely,
> Dmitry.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message