[
https://issues.apache.org/jira/browse/THRIFT-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16886609#comment-16886609
]
James E. King III commented on THRIFT-3165:
-------------------------------------------
Security moves along, and that made our title less than useful. It was:
Improve SSL Security in thrift by requiring TLS v1.2 by default
However really what we want to do is let the consumer control this.
In most languages we already disable SSLv2 and SSLv3.
Best practices now recommend only allowing TLSv1_3 or later, however Thrift
allows TLSv1_0 or later.
I modified the TSSLSocket code in C++ to eliminate SSLProtocol. If someone
wants to control the negotiation they need to subclass SSLContext and set the
options themselves, otherwise we'll be forever updating TSSLSocket with
protocol enhancements.
> 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.14#76016)
