Github user alopresto commented on the issue: https://github.com/apache/nifi/pull/1986 I'm sorry I'm late on this, but why are we trying to allow `SSLv3` for anything? I understand the original reason for this work was to be in line with the `PostHTTP` processor, but this makes outgoing connections to remote services, which may be legacy systems that do not support new TLS protocol versions. While I would discourage integrating with those systems as well, as `SSLv3` provides little effective security at this point, we are not exposing a vulnerability in NiFi by supporting that protocol version. Jetty intentionally disables any protocol version below `TLSv1.2`, and thus we require any incoming connections to support this protocol version. I believe the proper solution here is to remove `SSLv2` and `SSLv3` (along with `TLSv1` and `TLSv1.1`) from the dropdown list of the `SSLContextService` when used for *listening* (i.e. accepting incoming connections) as they will not be supported, rather than throwing an exception if an invalid one is selected (by my count, 5 of the 7 available are invalid for incoming connections -- `SSL`, `SSLv2Hello`, `SSLv3`, `TLSv1`, and `TLSv1.1`; `TLS` and `TLSv1.2` are valid).
--- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---