[
https://issues.apache.org/jira/browse/THRIFT-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III updated THRIFT-3165:
--------------------------------------
Component/s: (was: Smalltalk - Library)
(was: Ruby - Library)
(was: Python - Library)
(was: PHP - Library)
(was: Perl - Library)
(was: OCaml - Library)
(was: Node.js - Library)
(was: Lua - Library)
(was: JavaScript - Library)
(was: JavaME - Library)
(was: Java - Library)
(was: Haxe - Library)
(was: Haskell - Library)
(was: Go - Library)
(was: Erlang - Library)
(was: Delphi - Library)
(was: D - Library)
(was: Cocoa - Library)
(was: C++ - Library)
(was: C# - Library)
(was: C glib - Library)
(was: AS3 - Library)
Wish List
> Improve SSL Security in thrift by requiring TLS v1.2 by default
> ---------------------------------------------------------------
>
> Key: THRIFT-3165
> URL: https://issues.apache.org/jira/browse/THRIFT-3165
> Project: Thrift
> Issue Type: Improvement
> Components: Wish List
> Affects Versions: 0.9.2
> Reporter: James E. King III
> Priority: Major
> Labels: SSL, SSLSocketFactory, Security, TLS
>
> Thrift provides an SSL implementation and as such we need to ensure that
> thrift as a distribution is not the source of a security risk. Currently
> there is no uniformity across the library implementations to require a
> certain level of security for SSL communications.
> It is therefore proposed that the Thrift project require all SSL
> implementations shipping with the distribution to require TLS 1.2 or later as
> the accepted ciphers for a server socket. TLS 1.2 was defined in RFC 5246 in
> August of 2008.
> By shipping thrift with anything less, the finger can potentially be pointed
> back at thrift as a project for not providing the proper security. By
> setting the bar as high as possible on components in the package, the third
> party using Thrift must make a conscious decision to add other ciphers that
> are not as strong as TLS 1.2. Since the third party is making this decision,
> they are fully accepting the consequences of their action.
> Given this affects all SSL implementations, it could be done in one commit or
> in multiple commits; if the work is to be split up then it should be done
> with subtasks in Jira.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)