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
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:
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
I don't think that's a big deal. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
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/)
Geoffrey Talvola 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? 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
I don't think that's a big deal. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
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