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.
---
