nifi-issues mailing list archives

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


Dmitry Mashkov commented on NIFI-7064:


Let me comment some statements and make more clear my use case.

First of all, all certificates are self-signed, but it's just FYI.

Clients are issued certificate with fake domain name, like my.terminal1, for example.

NiFi issued almost the same, nifi.server plus SAN with IP added into certificate.

Next, we are exchanged certificates and put them into trusted keystore, of cource.

All communications will be established by IP address due to case.


Now, schema, all communication are two way,

Step 1) Clients [act as Client] connect to NiFi [as as Server] provides some information(and
IP address) and let send heartbits. Here I'm using {{HandleHTTPrequest/Response. 2waySSL.}}

Step 2) Now we exchange our roles, Clients [act as Server] have own services and NiFi [act
as Client]  uses \{{InvokeHTTP}} and send control command toward clients. 2waySSL. 

And please, take a look into RFC6125, Appendix B.2 HTTP

??If the client has external information as to the expected identity of
 the server, the hostname check MAY be omitted. (For instance, a
 client may be connecting to a machine whose address and hostname are
 dynamic but the client knows the certificate that the server will
 present.) In such cases, it is important to narrow the scope of
 acceptable certificates as much as possible in order to prevent man
 in the middle attacks. In special cases, it may be appropriate for
 the client to simply ignore the server's identity, but it must be
 understood that this leaves the connection open to active attack.??


This case is fully comply to RFC6125 from my point of view.




> Support 2-way SSL by InvokeHTTP processor
> -----------------------------------------
>                 Key: NIFI-7064
>                 URL:
>             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

View raw message