thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jeking3 <>
Subject [GitHub] thrift issue #1449: THRIFT-4434. Update .NET Core components, add tests for ...
Date Fri, 12 Jan 2018 16:57:19 GMT
Github user jeking3 commented on the issue:
    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
    Implementing that across the board would be verified by modifying 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.


View raw message