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.
--- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---