[
https://issues.apache.org/jira/browse/NIFI-4881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16367636#comment-16367636
]
Andy LoPresto commented on NIFI-4881:
-------------------------------------
This is an opt-in feature, so the automatic updates would only occur on a
system where an administrator has explicitly enabled this feature.
NiFi would not restart and update without a new definition delivery, and the
current definition would be cached locally, so I do not foresee any issues
starting up if connectivity to the remote endpoint is unavailable.
> Provide TLS "auto-secure" feature
> ---------------------------------
>
> Key: NIFI-4881
> URL: https://issues.apache.org/jira/browse/NIFI-4881
> Project: Apache NiFi
> Issue Type: New Feature
> Components: Configuration Management, Core Framework
> Affects Versions: 1.5.0
> Reporter: Andy LoPresto
> Assignee: Andy LoPresto
> Priority: Major
> Labels: security, tls
>
> As documented in the Apache NiFi Wiki Feature Roadmap (Security), I have
> wanted to implement for some time a feature where the administrator of a NiFi
> instance does not have to know the intricate details of TLS configuration in
> order to deploy a secure instance. What I propose is the following:
> * The administrator can set the TLS security settings to *high*, *medium*,
> and *low*
> * These settings have accompanying descriptions explaining that "*high*
> means most secure (with lower backwards compatibility)", "*medium* tries to
> strike a balance between security and compatibility", and "*low* allows for
> more widespread legacy compatibility with less emphasis on security".
> * The cipher suite lists and protocol versions for each would be downloaded
> from the [Mozilla TLS
> Observatory|https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations],
> which publishes updated definitions for each of "modern", "intermediate",
> and "legacy" options at initial startup and at regular intervals.
> * For deployments in an airgapped or other environment without desired
> connectivity to this service, or where the source is preferred to be
> controlled by an organizational entity, an alternate service endpoint can be
> configured (for proof of concept, this could even be the NiFi instance itself
> reading a file from disk and returning JSON over an HTTP endpoint).
> * When a new definition is received or selected, the application framework
> would either:
> ** Restart the Jetty server automatically in a pre-configured timeframe
> ** Wait for all queues to empty and then restart
> ** Provide a visual alert (bulletin, etc.) that new definitions were
> received and a manual restart is required
> * This setting could be set in a variety of ways:
> ** Directly in {{nifi.properties}} before the first application launch
> ** Given as an argument to an enhanced TLS Toolkit (i.e.
> {{./bin/tls-toolkit.sh standalone ... -S high}}) and then the resulting
> {{nifi.properties}} placed in the correct location
> ** Through a UI configuration option (this would need to be restricted to
> the appropriate NiFi permissions and would require a Jetty server restart)
> * The definitions would "grow" with the ecosystem (i.e. as a new
> vulnerability is discovered or a new protocol version/cipher suite is made
> available, it is automatically added/removed from the definition, thus
> continually improving the security stance of the application without
> requiring active monitoring and input from an administrator)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
