Nifi SSL TLS qestion

[#1]

When we enabled HTTPS with Nifi  using certificates.  Do we know if NIFI is using SSL or TLS, and what version of SSL or TLS is being  used.   Is there a way to dictate TLS 1.2 for NIFI to use?

[#2 · Accepted solution]

@Love-Nifi 

What is your NiFi Version?     From NiFi 1.2.0 release it should be default to TLS 1.2 as per
https://issues.apache.org/jira/browse/NIFI-3720
Snippet from JIRA:

Users/client connecting to NiFi through the UI or API now protected with TLS v1.2. TLSv1/1.1 are no longer supported.

https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.2.0

Snippet from the Doc:

Security
Users/client connecting to NiFi through the UI or API now protected with TLS v1.2 due to upgrade to Jetty version 9.4.2

So if you are using HDF then please check the NiFi Version. For example HDF3.0 (NiFi 1.2.0) will allow TLS 1.2 for all in coming connections. Other TLS versions will still be used for outgoing connections.

.

In General,  One option to disable all TLS protocols except TLSv1.2, can be achieved by editing "$JAVA_HOME/jre/lib/security/java.security" file. Here JAVA_HOME is the one which is used by NiFi process and  changing the "jdk.tls.disabledAlgorithms" property value to something like following as mentioned in https://java.com/en/configure_crypto.html

Example:

jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize, SSLv2Hello, TLSv1, TLSv1.1 < 768

.

You can further validate your NiFi by using the OpenSSL commands as following to attempt to connect to it using different options like following

# openssl s_client -connect <NiFIhostname>:<port>


# openssl s_client -connect <NiFIhostname>:<port> -tls1_2 
# openssl s_client -connect <NiFIhostname>:<port> -tls1_2 
# openssl s_client -connect <NiFIhostname>:<port> -tls1
# openssl s_client -connect <NiFIhostname>:<port> -ssl3

.

[#3]

 @Love-Nifi 

Just wanted to add that as @jsensharma mentioned, NiFi will enforce TLS 1.2 as of Apache NiFi release version 1.2.0 but only for all inbound connections to NiFi.  NiFi can still support negotiating lower TLS version when making outbound connections in order to support older destination systems.  Those processor would use a sslContextService which can be configured to restrict what TLS version is used/allowed.

[#4]

What TLS version does NiFi 1.17.0 use for outgoing connections by default when an SSLContextService is not configured? For example on a PutS3Object processor.

[#5]

@niclyx 

While NiFi only supports TLS 1.2 inbound connections, it will support lower TLS version for outgoing. The TLS version used is negotiated between client (NIFi) and server end point during the TSL exchange.  The highest level supported by both client and server is what will end up being used.

@apmmahesh 

Authentication and Authorization are two separate process in NiFi.  Successful Authentication will result in an user identity string (case sensitive) which is then passed to the authorization process to verify if the that identity string has been authorized for the requested resource.  In order to access the NiFI UI, users must be authorized to "view the user interface".

The authorization is configured in the authorizers.xml.  I am not sure which authorizer or providers you are using.  Most commonly used is the managed authorizer, File-access-policy-provider, and File-user-group-provider.  But you might also be using the ldap-user-group-provider.   

The file-access-policy-provider is used to setup necessary policies for the initial admin and nodes (if multi-node NiFi cluster) in an authorizations.xml file.  Within the file-access-policy provider you would define your initial admin user identity string "xyz123" so that the polcies need to be admin are assigned to this user identity.  Keep in mind the file-access-policy provider will only generate an authorizations.xml file if it does NOT already exist.  So if you edit the initial admin or NiFi nodes later, this changes willl not be reflected in the already existing authorizations.xml.  You'll need to delete current so new is generated.

Before the file access-policy-provider can setup initial admin policies for user "xyz123", the authorizer needs to be able to return that user identity (case sensitive) from one of the configured user-group-provider configured on the authorizers.xml.   You can use the file-user-group-provider to manually add user identities to NiFi for purpose of setting up aithorization (in this case their is an initial user identity 1 property you would add "xyz123" to.  Optionally you can setup the ldap-user-group-provider to sync user and group identities from your ldap server.  Keep in mind that two providers can not return the same identity. So if you are syncing from LDAP, don't configure the same user identity in the file-user-group-provider.  

here are the relevant Apache NiFi docs on these providers:
https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#fileusergroupprovider

https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#ldapusergroupprovider

https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#composite-implementations

https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#fileaccesspolicyprovider

https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#standardmanagedauthorizer

If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped.

Thank you,

Matt

[#6]

Hi Matt, thanks. 

Is there any official documentation that mentions this TLS version negotiation?

[#7]

@niclyx 
I think you are diverging form the original query asked in this community question which has an accepted solution. When it comes to a mutual TLS exchange/handshake, this is not something NiFi created or has made any modification to.  There are many different resources on the web to learn about MutualTLS and how it works.  NiFi only cares that the TLS handshake was successful and if no other method of authentication was setup, it received a clientAuth certificate from which it will use the full DN as the identity for the authenticated user.

I recommend starting a new community questions if you have new questions.

Matt