RE: [Python-Dev] the new 2.3a1 settimeout() with httplib and SSL
An update: I've uploaded a new patch to set BIO to be non-blocking when necessary and to retry properly when the SSL error code indicates it: http://sourceforge.net/tracker/index.php?func=detail&aid=676472&group_id=547 0&atid=305470 And, as a result of properly retrying on SSL_connect, it happens to also fix this bug when socket.setdefaulttimeout() is used in conjunction with ssl: http://sourceforge.net/tracker/index.php?func=detail&aid=673797&group_id=547 0&atid=105470 I've asked Ben Laurie to review the patch for me. Once he says it looks OK I'll assign both the bug and the patch to Guido to deal with. Hopefully it's finally right. - Geoff
-----Original Message----- From: Ben Laurie [mailto:ben@algroup.co.uk] Sent: Tuesday, January 28, 2003 11:53 AM To: Geoffrey Talvola Cc: 'python-dev@python.org' Subject: Re: [Python-Dev] the new 2.3a1 settimeout() with httplib and SSL
Geoffrey Talvola wrote:
Ben Laurie [mailto:ben@algroup.co.uk] wrote:
Guido van Rossum wrote:
Hm, from that page it looks like the internal implementation may actually repeatedly read from the socket, until it has processed a full 16K block. But I may be mistaken, since it also refers to a non-blocking underlying "BIO", whatever that is. :-(
BIO is OpenSSL's I/O abstraction - if you have a nonblocking one, then SSL_read() will return when a read returns nothing, and if you want SSL_read() to not block, then you pretty much have to use a non-blocking BIO (because even if select() says there's data, there may not be enough to actually return any via SSL_read()).
That's OK, I think, because what we care about with timeouts is detecting when there is _no_ activity on the socket for more than N seconds, and select() does detect that situation properly.
I can help out here if there's still a problem.
If you'd like, you could quickly review the latest checkin here -- I have no prior experience with OpenSSL so that might be prudent:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Module s/_ssl.c
But it seems to work fine.
Yeah, but there are corner cases where it won't. If the other end dies partway through sending an SSL record, then your select will succeed, but the SSL_read will block forever (or at least until the socket closes). You do need to put the socket and BIO into a non-blocking mode for this to work properly. I can't remember whether you get an error or a 0 back (I think its an error) when the socket would block, but in any case, that would need to be handled (presumably by going back around for the remaining time). If you need more info, I can find it :-) Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Geoffrey Talvola wrote:
An update:
I've uploaded a new patch to set BIO to be non-blocking when necessary and to retry properly when the SSL error code indicates it: http://sourceforge.net/tracker/index.php?func=detail&aid=676472&group_id=547 0&atid=305470
And, as a result of properly retrying on SSL_connect, it happens to also fix this bug when socket.setdefaulttimeout() is used in conjunction with ssl: http://sourceforge.net/tracker/index.php?func=detail&aid=673797&group_id=547 0&atid=105470
I've asked Ben Laurie to review the patch for me. Once he says it looks OK I'll assign both the bug and the patch to Guido to deal with. Hopefully it's finally right.
Doesn't seem quite right to me yet - the problem is that if data arrives 1 byte at a time with just less than the timeout between each byte, then you can get n*timeout as the actual timeout (where n is potentially very large). You need to reduce the timeout after each select, surely? Apart from that, it looks good. Apologies for delay, I managed to overlook this. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Doesn't seem quite right to me yet - the problem is that if data arrives 1 byte at a time with just less than the timeout between each byte, then you can get n*timeout as the actual timeout (where n is potentially very large). You need to reduce the timeout after each select, surely?
I don't think that's a big deal. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
Doesn't seem quite right to me yet - the problem is that if data arrives 1 byte at a time with just less than the timeout between each byte, then you can get n*timeout as the actual timeout (where n is potentially very large). You need to reduce the timeout after each select, surely?
I don't think that's a big deal.
If its documented that the timeout is an order-of-magnitude thing that is susceptible to DoS attacks, then I guess not. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
If its documented that the timeout is an order-of-magnitude thing that is susceptible to DoS attacks, then I guess not.
I would think that anything that doesn't specifically document it's safe against DoS attacks should be considered susceptible to them. I see no need to document this. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (3)
-
Ben Laurie -
Geoffrey Talvola -
Guido van Rossum