thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James E. King III (JIRA)" <>
Subject [jira] [Commented] (THRIFT-3165) Improve SSL Security in thrift by requiring TLS v1.2 by default
Date Wed, 17 Jul 2019 01:47:00 GMT


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:
>             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

View raw message