Hello, > Would you please confirm to the list the name of the Python module, the > download site for it and the version you are currently working with. > This just helps up provide assistance to this same question in future.
This is with Python trunk (from SVN). The error is easily witnessed when running Lib/test/test_ftplib.py after building Python against OpenSSL 0.9.8m (or 1.0.0 in my case). I suppose a 2.6.5 release version of Python would show similar problems, except that TLS support for FTP is new in 2.7/trunk, which makes it less easy to reproduce. > Please read up on this recent thread. I do not know anything about > Python modules myself but I believe this user was also debugging a > similar issue. > > http://www.mail-archive.com/openssl-users@openssl.org/msg60444.html Well, not exactly. This issue (ERROR_WANT_READ / ERROR_WANT_WRITE) can be fixed in our test cases, by doing the shutdown correctly, and indeed I've got a patch for that. What I'm specifically interested in is SSL_ERROR_SYSCALL with errno==0. These issues are tracked together at http://bugs.python.org/issue8108 , because they both appeared when someone tried OpenSSL 0.9.8m. (there are also a couple of 1.0.0-specific issues which seem negotation-related, and which we'll have to tackle separately) > What SSL_shutdown() is saying by returning -1/ERROR_SYSCALL is that a > cryptographically two-way shutdown of the stream was _NOT_ completed and > that it will probably not be able to ever be completed, probably due to > the fact the underlying socket died on us. Ok, thanks for the clarification. We were a bit baffled by errno==0 (EPIPE, ECONNABORTED, EBADF... would have been much more helpful). So, in any case, I can interpret an SSL_ERROR_SYSCALL return from SSL_shutdown() as "the socket was closed more or less abruptly" response? There are no other possible reasons for this error return? > But to > be a good well meaning TLS/SSL citizen both ends should continue their > non-blocking event loops for a reasonable amount of time (in the order > of 5 to TCP timeout seconds) even after the last SSL_write() has been > made. He, well. The interesting thing here is that we are testing a blocking FTP TLS client with a non-blocking (event loop-based) server. The blocking client can't really sleep() for 5 seconds when closing the FTP session. At least I think users wouldn't like it :-) Also, the client doesn't try to shutdown the SSL layer when closing its connection. According to the client's author, this is contrary to the RFC. In his own words: ftplib.FTP_TLS class already calls unwrap() but only when closing a "secured" *data* connection. This is never done for the *control* connection as the examples shown in RFC-4217 do that only when dealing with the CCC command which is intended to switch the control connection back to clear text. Since ftplib.py does not implement the CCC command I would avoid to override its close() method. (if you have an opinion on this specific point -- no implicit SSL shutdown when closing the FTP session --, I'd like to hear it. Although it isn't really part of the issue at hand). > So you have to stand back for a moment and examine Python's use of the > OpenSSL API and decide if you are trying to be 1:1 as much as possible > to support and pass on all the cryptographic guarantees that OpenSSL > makes or if you are trying to provide a simplified view of the world > that Noddy and Big-Ears could use. Heh :) We definitely want to provide a thin layer over OpenSSL, and not hide any legitimate error conditions, as far as these conditions provide useful feedback to the user (errno==0 being a bit disturbing :-)). Our SSL support is definitely not newbie-proof. (If you are curious, some precisions. There are actually two layers in our abstraction: - the "_ssl" extension module is a thin C wrapper - the "ssl" library module provides a higher-level (but not that much) socket-alike abstraction over it. Even "ssl", though, doesn't really try to hide any strange conditions. The one thing I think is worth abstracting (and part of my patches) is when SSL_shutdown returns ERROR_WANT_{READ,WRITE} *and* the socket is in *blocking* mode. In that case, shipping the select-and-retry loop as part of the ssl abstraction, instead of having each user replicate the boring logic, looks reasonable to me. What do you think? ending the parenthesis here --> ) Thanks for the explanations. Regards, Antoine. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
