[
https://issues.apache.org/jira/browse/THRIFT-3061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14485091#comment-14485091
]
James E. King, III commented on THRIFT-3061:
--------------------------------------------
[~roger.meier] I respectfully disagree here, since the code in TSSLSocket is
clearly closing the socket following the shutdown sequence. The second
shutdown call is only necessary if the socket is going to be reused and this is
documented in the SSL_shutdown manual page. As it is, a malicious client can
hold the server connection hostage by opening a SSL connection and then only
responding to the first SSL_Shutdown, and not respond to the second; further
not all SSL clients on all platforms and in all languages adhere to the "close
notify" part properly (but most do) as we've seen this behavior with older C#
clients connected. Please reconsider.
> C++ TSSLSocket shutdown delay/vulnerability
> -------------------------------------------
>
> Key: THRIFT-3061
> URL: https://issues.apache.org/jira/browse/THRIFT-3061
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
> Affects Versions: 0.8, 0.9, 0.9.1, 0.9.2
> Reporter: James E. King, III
> Assignee: Roger Meier
> Labels: OpenSSL, SSL
> Attachments: THRIFT-3061.patch
>
>
> In the C++ implementation of TSSLSocket, during close() the following code
> sequence is found:
> {noformat}
> void TSSLSocket::close() {
> if (ssl_ != NULL) {
> int rc = SSL_shutdown(ssl_);
> if (rc == 0) {
> rc = SSL_shutdown(ssl_);
> }
> {noformat}
> According to the OpenSSL documentation, while it is "nice" to attempt to
> shutdown SSL in this way, it is not required when the code is performing a
> unilateral shutdown (meaning the underlying connection will be closed). It
> is only necessary to call SSL_Shutdown twice like this if the socket (and
> configured SSL therein) is going to be reused.
> It is possible to have a misbehaving client that does not handle this part of
> the shutdown process properly and fail to reply, and also fail to close. The
> most likely embodiment would be a program designed specifically to fail to
> reply to the "close notify" and hold the socket open in order to produce a
> denial-of-service attack. Another possibility is a poorly written client.
> Given the OpenSSL documentation states that calling SSL_Shutdown once is
> sufficient when the socket is going to be closed, I recommend that we remove
> the second SSL_Shutdown call and prevent something that can block the close()
> call. We have seen this happen, and it interacts with THRIFT-2441.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
