[
https://issues.apache.org/jira/browse/NIFI-2528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16099301#comment-16099301
]
ASF GitHub Bot commented on NIFI-2528:
--------------------------------------
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).
> Update ListenHTTP to honor SSLContextService Protocols
> ------------------------------------------------------
>
> Key: NIFI-2528
> URL: https://issues.apache.org/jira/browse/NIFI-2528
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
> Affects Versions: 1.0.0, 0.8.0, 0.7.1
> Reporter: Joe Skora
> Assignee: Michael Hogue
>
> Update ListenHTTP to honor SSLContextService Protocols as [NIFI-1688] did for
> PostHTTP.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
