[issue29970] Severe open file leakage running asyncio SSL server
kyuupichan added the comment: @Nikolay Kim As I note in the original submission, 480 was tested and does NOT solve this issue. Thanks. -- ___ Python tracker <http://bugs.python.org/issue29970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29970] Severe open file leakage running asyncio SSL server
New submission from kyuupichan: Original report at old repo here: https://github.com/python/asyncio/issues/483 There this is reported fixed by https://github.com/python/cpython/pull/480 I wish to report that whilst the above patch might have a small positive effect, it is far from solving the actual issue. Several users report eventual exhaustion of the open file resource running SSL asyncio servers. Here are graphs provided by a friend running my ElectrumX server software, first accepting SSL connections and the second accepting TCP connections only. Both of the servers were monkey-patched with the pull-480 fix above, so this is evidence it isn't solving the issue. http://imgur.com/a/cWnSu As you can see, the TCP server (which has far less connections; most users use SSL) has no leaked file handles, whereas the SSL server has over 300. This becomes an easy denial of service vector against asyncio servers. One way to trigger this (though I doubt it explains the numbers above) is simply to connect to the SSL server from telnet, and do nothing. asyncio doesn't time you out, the telnet session seems to sit there forever, and the open file resources are lost in the SSL handshake stage until the remote host kindly decides to disconnect. I suspect these resource issues all revolve around the SSL handshake process, certainly at the opening of a connection, but also perhaps when closing. As the application author I am not informed by asyncio of a potential connection until the initial handshake is complete, so I cannot do anything to close these phantom socket connections. I have to rely on asyncio to be properly handling DoS issues and it is not currently doing so robustly. -- components: asyncio messages: 291071 nosy: kyuupichan, yselivanov priority: normal severity: normal status: open title: Severe open file leakage running asyncio SSL server type: resource usage versions: Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue29970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30105] Duplicated connection_made() call for some SSL connections
New submission from kyuupichan: An asyncio SSL server frequently sees duplicated connection_made() calls for an incoming SSL connection. It does not happen to all SSL connections; perhaps 10-25% of them. It never happens to TCP connections. Here are some examples of logs from one I run. I see this on MacOSX and DragonflyBSD, others have reported the same on Linux, so I believe it's a quirk in asyncio and not O/S specific. I assume it is a bug in the wrapping of the raw TCP transport with an SSL one. 2017-04-20 07:22:44.676180500 INFO:ElectrumX:[14755] SSL 218.185.137.81:52844, 256 total 2017-04-20 07:22:45.666747500 INFO:ElectrumX:[14756] SSL 218.185.137.81:52847, 256 total The log is output on a connection_made() callback to a protocol, and not from the protocol's constructor. They are very close together, from the same IP address and ports that are close together. The first connection was closed with connection_lost() before the 2nd connection_made() because the total session count (here 256) did not increase. Here is another section of my log with 2 more examples. Totals are not monotonic because of course disconnections (not logged) happen all the time. 2017-04-20 07:30:31.529671500 INFO:ElectrumX:[14796] SSL 193.90.12.86:42262, 259 total 2017-04-20 07:31:04.434559500 INFO:ElectrumX:[14797] SSL 70.199.157.209:10851, 259 total 2017-04-20 07:31:05.765178500 INFO:ElectrumX:[14798] SSL 70.199.157.209:10877, 259 total 2017-04-20 07:31:32.305260500 INFO:ElectrumX:[14799] SSL 64.113.32.29:35025, 256 total 2017-04-20 07:31:44.731859500 INFO:ElectrumX:[14800] SSL 188.107.123.236:60867, 255 total 2017-04-20 07:31:45.504245500 INFO:ElectrumX:[14801] SSL 188.107.123.236:60868, 255 total 2017-04-20 07:31:48.943430500 INFO:ElectrumX:[14802] SSL 136.24.49.122:54987, 255 total 2017-04-20 07:31:59.967676500 INFO:ElectrumX:[14803] TCP 113.161.81.136:2559, 256 total 2017-04-20 07:32:03.249780500 INFO:ElectrumX:[14804] SSL 69.121.8.201:63409, 256 total Another reason I believe this is an asyncio issue on the server side is that someone else's server software that doesn't use asyncio logs in a similar way and does not see duplicated incoming "connections". -- components: asyncio messages: 291919 nosy: kyuupichan, yselivanov priority: normal severity: normal status: open title: Duplicated connection_made() call for some SSL connections type: behavior versions: Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue30105> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33093] Fatal error on SSL transport
kyuupichan added the comment: Looks like https://bugs.python.org/issue33037 -- nosy: +kyuupichan ___ Python tracker <https://bugs.python.org/issue33093> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29970] Severe open file leakage running asyncio SSL server
kyuupichan added the comment: I'm not sure what you mean about this being a server-specific problem. It's clearly a bug in the asyncio SSL wrapper as using TCP instead of SSL with otherwise identical code doesn't leak open files. -- ___ Python tracker <https://bugs.python.org/issue29970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
