Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1449
The log is there:
```
===============================================================================
*** Following 1 failures were unexpected ***:
If it is introduced by you, please fix it before submitting the code.
===============================================================================
server-client: protocol: transport: result:
csharp-tls binary buffered-ip-ssl
failure(3)
===============================================================================
```
There is a security feature test in test/features called tls and it
verifies that the server accepts a TLS connection. It verifies that a TLSv1.0,
TLSv1.1, or TLSv1.2 client can connect successfully. If this is failing then
something changed in the code that restricted the TLS to one level.
We currently use SSLv23 handshake and disable the use of SSLv2 and SSLv3,
so that the client can connect at TLSv1.0 or higher.
There's a story in the backlog to move all languages by default up to
TLSv1.2 to improve security.
https://issues.apache.org/jira/browse/THRIFT-3165
Implementing that across the board would be verified by modifying tls.sh in
test/features so that TLSv1.0 and TLSv1.1 was NOT expected to allow a
connection by default.
What I have found is that if you specify a handshake at TLSv10, then ONLY
TLSv1.0 is allowed to connect. It doesn't allow TLSv1.1 or TLSv1.2 to
connect. If you specify a SSLv23 handshake, but disable SSLv2 and SSLv3
negotiation, then any client can connect and they can only negotiate at TLSv1.0
or later, which is the current behavior we have.
---
