Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NIFI-1930 Updated ListenHTTP to set TLS included protocols #4687

Closed
wants to merge 2 commits into from

Conversation

exceptionfactory
Copy link
Contributor

@exceptionfactory exceptionfactory commented Nov 25, 2020

Description of PR

NIFI-1930 Updated ListenHTTP to configure the Jetty SslContextFactory with included protocols based on the configuration of the SSLContextService TLS Protocol property. The Jetty SslContextFactory will be configured to support multiple current TLS protocol versions when the TLS Protocol is configured without a specific version. When the SSLContextService TLS Protocol property specifies a particular TLS Protocol version, only that version will be allowed.

This update simplifies the configuration of the Jetty SslContextFactory by using the SSLContext created from SSLContextService, as opposed to passing the individual key store and trust store properties. This update also introduces a new Client Auth property for ListenHTTP to explicitly define the TLS client authentication policy. Previous versions of ListenHTTP inferred the client authentication policy based on the presence or absence of trust store properties in the SSLContextService. The Client Auth property is defaulted to REQUIRED to support mutual TLS authentication, but all standard values are supported.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

For all changes:

  • Is there a JIRA ticket associated with this PR? Is it referenced
    in the commit message?

  • Does your PR title start with NIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

  • Has your PR been rebased against the latest commit within the target branch (typically main)?

  • Is your initial contribution a single, squashed commit? Additional commits in response to PR reviewer feedback should be made on this branch and pushed to allow change tracking. Do not squash or use --force when pushing to allow for clean monitoring of changes.

For code changes:

  • Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder?
  • Have you written or updated unit tests to verify your changes?
  • Have you verified that the full build is successful on JDK 8?
  • Have you verified that the full build is successful on JDK 11?
  • If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
  • If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly?
  • If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly?
  • If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties?

For documentation related changes:

  • Have you ensured that format looks appropriate for the output in which it is rendered?

Note:

Please ensure that once the PR is submitted, you check GitHub Actions CI for build issues and submit an update to your PR as soon as possible.

@thenatog
Copy link
Contributor

Will review this one as well.

@thenatog
Copy link
Contributor

Tested out ListenHTTP processor in combination with the RestrictedSslContextService. I set the protocols explicitly to TLSv1.2 and TLSv1.3 and only those were enabled (I checked this with openssl s_client and Wireshark), and ListenHTTP offered those protocols respectively. 'TLS' setting allowed both TLSv1.2 and TLSv1.3 as expected. I used PostHTTP and ListenHTTP to talk to each other and set TLSv1.2 on PostHTTP and TSLv1.3 on ListenHTTP and there was a protocol version mismatch error as expected.

@exceptionfactory
Copy link
Contributor Author

@thenatog Thanks for the review and testing. The introduction of the Client Authentication property and streamlining the initialization process to call SSLContextService.createSSLContext() apparently broke implicit support for one-way TLS communication, which ListenHTTP supported when the SSLContextService did not have any Trust Store properties configured. I pushed an update to this PR that includes an update to SSLContextService and SslContextFactory that restores support for this configuration, but logs a warning message indicating that the default platform Certificate Authorities will be used. This adjustment reduced the impact to existing unit tests and preserves backwards compatibility.

@thenatog
Copy link
Contributor

+1 LGTM, will merge.

@thenatog
Copy link
Contributor

Merged

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants