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 [email protected] or file a JIRA ticket
with INFRA.
---
