[ python-Bugs-978833 ] SSL-ed sockets don't close correct?
SourceForge.net
noreply at sourceforge.net
Sat Sep 24 21:45:46 CEST 2005
Bugs item #978833, was opened at 2004-06-24 11:57
Message generated for change (Comment added) made by kxroberto
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978833&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 8
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Brett Cannon (bcannon)
Summary: SSL-ed sockets don't close correct?
Initial Comment:
When testing FTP over SSL I have strong doubt, that
ssl-ed sockets are not closed correctly. (This doesn't
show with https because nobody takes care about whats
going on "after the party".) See the following :
---
I need to run FTP over SSL from windows (not shitty
sftp via ssh etc!)
as explained on
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html
(good variant
3: FTP_TLS )
I tried to learn from M2Crypto's ftpslib.py (uses
OpenSSL - not
Pythons SSL) and made a wrapper for ftplib.FTP using
Pythons SSL.
I wrap the cmd socket like:
self.voidcmd('AUTH TLS')
ssl = socket.ssl(self.sock, self.key_file,
self.cert_file)
import httplib
self.sock = httplib.FakeSocket(self.sock, ssl)
self.file = self.sock.makefile('rb')
Everything works ok, if I don't SSL the data port
connection, but only
the
If I SSL the data port connection too, it almosts work,
but ...
self.voidcmd('PBSZ 0')
self.voidcmd('PROT P')
wrap the data connection with SSL:
ssl = socket.ssl(conn, self.key_file,
self.cert_file)
import httplib
conn = httplib.FakeSocket(conn, ssl)
than in retrbinary it hangs endless in the last 'return
self.voidresp()'. all data of the retrieved file is
already correctly
in my basket! The ftp server just won't send the final
'226 Transfer
complete.' on the cmd socket. Why?
def retrbinary(self, cmd, callback, blocksize=8192,
rest=None):
self.voidcmd('TYPE I')
conn = self.transfercmd(cmd, rest)
fp = conn.makefile('rb')
while 1:
#data = conn.recv(blocksize)
data = fp.read() #blocksize)
if not data:
break
callback(data)
fp.close()
conn.close()
return self.voidresp()
what could be reason?
The server is a ProFTPD 1.2.9 Server.
I debugged, that the underlying (Shared)socket of the
conn object is
really closed.
(If I simly omit the self.voidresp(), I have one file
in the box, but
subsequent ftp communication on that connection is not
anymore
correct.)
----------------------------------------------------------------------
>Comment By: Robert Kiendl (kxroberto)
Date: 2005-09-24 21:45
Message:
Logged In: YES
user_id=972995
Now I managed to solve the problem for me with attached
patch of httplib.py: a explicit shutdown ( 2 or 1 ) of the
(faked) ssl'ed socket solves it.
I still guess the ssl'ed socket (ssl dll) should do that
auto on sock.close()
Thus I leave it as a bug HERE. Right?
[ I also have the hope, that this also solves the
ssl-eof-errors with https (of some of my users; will see
this in future)
*** \usr\src\py24old/httplib.py Sat Sep 24 21:35:28 2005
--- httplib.py Sat Sep 24 21:37:48 2005
*************** class SharedSocket:
*** 899,904 ****
--- 899,905 ----
self._refcnt -= 1
assert self._refcnt >= 0
if self._refcnt == 0:
+ self.sock.shutdown(2)
self.sock.close()
def __del__(self):
----------------------------------------------------------------------
Comment By: Robert Kiendl (kxroberto)
Date: 2005-09-24 21:06
Message:
Logged In: YES
user_id=972995
I retried that again with py2.4.1. The problem/bug is still
there.
In attachment I supplied a full FTPS client test_ftpslib.py
with simple test function - ready to run into the problem:
At the end of ftp.retrlines 'return self.voidresp()'
freezes : waiting eternally for response bytes at the
command port. the same at the end of .storelines after the
data is transfered on the data port.
My preliminary guess is still, that python's ssl has a
severe (EOF?) problem closing a socket/connection correctly.
obviously this problem doesn't show up with https because
everything is done on one connection - no dependency on a
correct socket/connect close signal.
(from other https communication with some proxies in between
my users get ssl-eof-error errors also. I still can't solve
that bug too. this shows python's ssl has a severe EOF bug
with complex https also - or cannot handle certain
situations correct.)
I learned the FTPS/TLS client from M2crypto's ftpslib. the
only difference in (transposed) logic, that I can see is,
that M2crpyto uses an additional line
"conn.set_session(self.sock.get_session())" during setup of
the data port ssl connection. I don't know what it is,
pythons ssl doesn't have sucht "session"-functions, but I
think it has no severe meaning.?
Robert
----------------------------------------------------------------------
Comment By: Brett Cannon (bcannon)
Date: 2004-12-22 06:14
Message:
Logged In: YES
user_id=357491
Since I believe this was fixed with the patch Tino mentions and Roberto
has not replied, I am closing as fixed.
----------------------------------------------------------------------
Comment By: Brett Cannon (bcannon)
Date: 2004-08-17 01:18
Message:
Logged In: YES
user_id=357491
Is this still a problem for you, Roberto, with Python 2.4a2?
----------------------------------------------------------------------
Comment By: Tino Lange (tinolange)
Date: 2004-07-11 00:30
Message:
Logged In: YES
user_id=212920
Hi Roberto!
Today a patch for _ssl.c was checked in (see #945642) that
might solve your problem, too.
Could you please grab the *next* alpha (this will be Python
2.4 Alpha 2) and test and report afterwards if it is solved?
Thanks for your help!
Tino
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978833&group_id=5470
More information about the Python-bugs-list
mailing list