This is not a bug, but rather a request for API improvements.

Correct SSL shutdown processing is frequent source of confusion. Python’s ssl module unfortunately lacks the flexibility to accommodate some common paradigms. 

The problem is that the unwrap() method of SSLObject and SSLSocket always blocks until it receives the peer’s close_notify alert. This is the sensible default since it is the most secure. However, it is also common (and secure) to send the close_notify and then shutdown the socket immediately after without waiting for the peer’s close_notify alert. More details can be found in section 7.2.1 of RFC 2246 and its successors. Another good source is the discussion at http://security.stackexchange.com/questions/82028/ssl-tls-is-a-server-always-required-to-respond-to-a-close-notify

To accommodate the range of SSL shutdown behaviors in the real world I propose two small API changes. One is to add a keyword argument to the unwrap() method of SSLSocket and SSLObject. The new keyword argument is wait_for_peer, and it’s default value should be True. unwrap(wait_for_peer=True) would be the default behavior, and would match the current behavior: always wait for the peer to send the close_notify. unwrap(wait_for_peer=False) however, would return successfully after sending the close_notify whether or not the peer has sent their close_notify. In addition, a new method ‘get_shutdown_state()’ is needed to retrieve the current shutdown state of the SSL connection or object. Or perhaps the method could be a simple boolean ‘has_peer_sent_shutdown()’.

This is just one proposal for adding some necessary flexibility with minimal API changes. Other approaches are possible.

Patches welcome! I don't have resources to work on a patch