[
https://issues.apache.org/jira/browse/THRIFT-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15862770#comment-15862770
]
ASF GitHub Bot commented on THRIFT-3165:
----------------------------------------
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1185
@gadLinux The current standard for thrift is to use the SSLv23 handshake,
but to negotiate at TLSv1.0 or later. See Apache Jira
https://issues.apache.org/jira/browse/THRIFT-3165 for that. Code to be checked
in today for SSL support should use "SSLTLS" and disable SSL v2 and v3
negotiation which is what I did. So no, we cannot change it to anything else
than what I put in my 3rd PR to you.
As a consuming application one should be able to set the accepted version.
I know you can do this in C++ and in Java because the constructors to
TSSLSocket take an enumeration. In your implementation here how can we change
it so that when a thrift_ssl_socket class is initialized, the consuming
application can decide the SSL versions to support? I'm not sure this
implementation allows for that control as-is.
@nsuke I think I found a way to make the code conditional on OP_NO_SSLv3
support instead of a Python version. I'll post once I get the syntax right.
> 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: AS3 - Library, C glib - Library, C# - Library, C++ -
> Library, Cocoa - Library, D - Library, Delphi - Library, Erlang - Library, Go
> - Library, Haskell - Library, Haxe - Library, Java - Library, JavaME -
> Library, JavaScript - Library, Lua - Library, Node.js - Library, OCaml -
> Library, Perl - Library, PHP - Library, Python - Library, Ruby - Library,
> Smalltalk - Library
> Affects Versions: 0.9.2
> Reporter: James E. King, III
> 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
(v6.3.15#6346)
