[jira] [Reopened] (THRIFT-3061) C++ TSSLSocket shutdown delay/vulnerability
[
https://issues.apache.org/jira/browse/THRIFT-3061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III reopened THRIFT-3061:
Assignee: James E. King, III (was: Roger Meier)
> 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: James E. King, III
> Labels: OpenSSL, SSL
> Fix For: 0.9.3
>
> 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)
[jira] [Reopened] (THRIFT-3061) C++ TSSLSocket shutdown delay/vulnerability
[
https://issues.apache.org/jira/browse/THRIFT-3061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roger Meier reopened THRIFT-3061:
-
> 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)
