New submission from Greg Stark: 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. ---------- assignee: christian.heimes components: SSL messages: 286674 nosy: Greg Stark, christian.heimes priority: normal severity: normal status: open title: ssl.SSLSocket.unwrap() is not flexible enough type: behavior versions: Python 3.5 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29413> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
