> 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
        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.



OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to