Pierrick FLORECK created NIFI-16325:
---------------------------------------
Summary: Support for TLS-encrypted ("HTTPS") forward proxies in
ProxyConfigurationService and processors relying on java.net.http.HttpClient
Key: NIFI-16325
URL: https://issues.apache.org/jira/browse/NIFI-16325
Project: Apache NiFi
Issue Type: Improvement
Components: NiFi API
Affects Versions: 2.8.0, 1.28.1, 1.8.0
Reporter: Pierrick FLORECK
*Problem*
Our environment requires all outbound traffic to leave through a corporate
forward proxy that itself only accepts TLS-encrypted connections (i.e. the
client must complete a TLS handshake with the proxy _before_ sending the
{{CONNECT}} request), in addition to requiring proxy authentication.
{{StandardProxyConfigurationService}} only exposes {{{}DIRECT{}}},
{{{}HTTP{}}}, and {{SOCKS}} as possible values for {_}Proxy Type{_}. There is
no way to declare that the connection to the proxy itself must be established
over TLS. As a result, processors that rely on this controller service — in our
case {{{}PublishGCPubSubHttp and InvokeHTTP{}}}, but this affects any processor
built on {{java.net.http.HttpClient}} or a proxy-aware HTTP client — cannot
reach the target service at all in this kind of environment.
*Root cause*
{{{}java.net.http.HttpClient{}}}'s internal connection model only ever
negotiates TLS with the _target_ server — either directly, or through a
{{CONNECT}} tunnel that is itself established over a *plaintext* connection to
the proxy. There is no code path for negotiating a TLS handshake with the proxy
itself first. This is a known architectural limitation of the JDK's HTTP
client, not something NiFi introduced, but NiFi currently has no way to work
around it either.
*Impact*
Any organization enforcing a TLS-terminated forward proxy for egress traffic (a
common pattern in zero-trust / SASE network architectures) cannot use
{{{}StandardProxyConfigurationService{}}}-based processors to reach external
endpoints.
*Suggested directions*
* Add an {{HTTPS}} (or {{{}TLS{}}}) value to _Proxy Type_ in
{{{}StandardProxyConfigurationService{}}}, with NiFi performing the TLS
handshake to the proxy itself before establishing the tunnel/request — this
would likely require a custom connection layer for affected processors rather
than relying solely on {{{}java.net.http.HttpClient{}}}'s native (and limited)
proxy support.
* At minimum, document this as a known limitation, ideally with a recommended
workaround (e.g. a local TLS-terminating relay such as stunnel or Squid between
NiFi and the corporate proxy) so other users don't have to rediscover it
independently.
*Environment*
* NiFi version: 2.8.0
* Processor(s) affected: {{PublishGCPubSubHttp, InvokeHTTP}} (would generalize
to any processor using {{{}StandardProxyConfigurationService{}}})
* Proxy: corporate HTTPS forward proxy with authentication
*Current workaround*
Running a local relay (stunnel/Squid) that terminates TLS toward the corporate
proxy and exposes a plaintext HTTP proxy to NiFi.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
