[
https://issues.apache.org/jira/browse/NIFI-7064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17041722#comment-17041722
]
Dmitry Mashkov edited comment on NIFI-7064 at 2/21/20 10:00 AM:
----------------------------------------------------------------
Shawn, Andy,
I deeply sorry, this is my mistake, please forget all above.
Please check a new patch, I only added host validation support for 2way SSL.
My case is follow:
1) NiFi act a server and use only IP, as result SAN added into certificate.
2) "Clients" are in "green field", uses only IP address, and IP address can be
changed dynamically as result IP address can't be added as SAN into
certificates.
Now I use 2 way SSL for secure communication and authentication each other. To
do so, "clients" will start communication and provide their IP addresses to
continue communication from NiFi toward clients as result host validators
should be added into client dynamically.
Also added into InvokeHTTP use password for private key, if provided in context
service.
Sincerely,
Dmitry
was (Author: dreadolph):
Shawn, Andy,
I deeply sorry, this is my mistake, please forget all above.
Please check a new patch, I only added host validation support for 2way SSL.
My case is follow:
1) NiFi act a server and use only IP, as result SAN added into certificate.
2) "Clients" are in "green field", uses only IP address, and IP address can be
changed dynamically as result IP address can't be added as SAN into
certificated.
Now I use 2 way SSL for secure communication and authentication each other. To
do so, "clients" will start communication and provide their IP addresses to
continue communication from NiFi toward clients as result host validators
should be added into client dynamically.
Also added into InvokeHTTP use password for private key, if provided in context
service.
Sincerely,
Dmitry
> 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,
> InvokeHTTP_2-way_SSL_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)
