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

Reply via email to