[
https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14183097#comment-14183097
]
Mamta A. Satoor commented on DERBY-6764:
----------------------------------------
Rick, if we decide to change the derby code so SSLv3 is not an available
option, would SSLSocket.setEnabledProtocols achieve the goal of removing SSLv3?
We could get a list of supported protocols using
SSLSocket.getSupportedProtocols() and remove SSLv3 from it(if it is in the
list) and then call setEnabledProtocols with the new list. (or is it better to
use SSLSocket.getEnabledProtocols() to get the list of enabled protocols and
remove SSLv3 from that list and use this new list for
SSLSocket.setEnabledProtocols).
If we go with this path, then I think we will not have to worry about what JVM
vendor we are working with.
> analyze impact of poodle security alert on Derby client - server ssl support
> ----------------------------------------------------------------------------
>
> Key: DERBY-6764
> URL: https://issues.apache.org/jira/browse/DERBY-6764
> Project: Derby
> Issue Type: Task
> Reporter: Myrna van Lunteren
>
> Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability
> (CVE-2014-3566)
> Derby supports ssl between the client and network server.
> We should investigate this and decide if we need to change our product, e.g.
> to eliminate support for SSL in favor of its successor TLS.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
