Visitar URL original
SSL socket exhaustion? · Issue #483 · python/asyncio · GitHub
Skip to content
This repository was archived by the owner on Nov 23, 2017. It is now read-only.
This repository was archived by the owner on Nov 23, 2017. It is now read-only.

SSL socket exhaustion? #483

Description

@kyuupichan

I have written a fairly widely used server, ElectrumX, with asyncio. This issue

kyuupichan/electrumx#94

is essentially about clients that connect to the SSL port and then do nothing during the SSL handshake. The number of connections doing this seems to gradually increase over time. It is easily confirmed these never time out by simply making a telnet connection to the SSL port and doing nothing.

An SSL server created with create_server() creates protocols using the protocol factory when the initial connection comes in, but because of the socket wrapping it will not call connection_made() until the handshake is complete. As a result it seems I have no way of getting the socket or the transport of these ghost connections, and therefore I cannot close them if stale. I also don't see anywhere I can specify SSL handshake timeouts in asyncio.

I've looked over the code and pored over the docs, but cannot find anything about this. Am I missing something obvious?

Activity

  1. kyuupichan commented on Jan 13, 2017

    @kyuupichan
    Author

    This would seem to be an easy avenue to exhaust the open file limit of any asyncio server that accepts SSL connections as it is out of the control of the application author.

    Should there not be some timeout on SSL handshakes - both initial handshake and shutdown handshake?

  2. Martiusweb commented on Jan 13, 2017

    @Martiusweb
    Member

    Hi,

    I didn't dig too deep, but it think that's indeed an issue which should be fixed: it's probably easy to DOS an asyncio server by keeping SSL connections open without completing the handshake.
    We don't need to do anything for client SSL streams, wrapping open_connection() (or the equivalent for other streams) in wait_for() with a timeout is sufficient.

    I'm interested in working on this. The simplest solution is probably to set a timeout on idle streams. We have to keep in mind that either solution must work for any kind of stream transport.

    I can look at how we can update the API to include a timeout argument to the right methods and coroutine functions.

  3. kyuupichan commented on Mar 28, 2017

    @kyuupichan
    Author

    Any progress on this? This is a huge flaw for asyncio SSL servers in a hostile environment.

  4. fafhrd91 commented on Mar 28, 2017

    @fafhrd91

    here is fix python/cpython#480

  5. kyuupichan commented on Mar 28, 2017

    @kyuupichan
    Author

    Fantastic, thank you. I hope this can be back-ported to 3.5.x and 3.6.x.

  6. fafhrd91 commented on Mar 28, 2017

    @fafhrd91

    fix is trivial, we can include it into aiohttp for old python versions.

  7. kyuupichan commented on Mar 28, 2017

    @kyuupichan
    Author

    aiohttp? Not using that; using simple SSL sockets with raw TCP

  8. fafhrd91 commented on Mar 28, 2017

    @fafhrd91

    ah, ok. just saw aiohttp in install_requires.
    then you can do monkey patch yourself.

  9. kyuupichan commented on Mar 28, 2017

    @kyuupichan
    Author

    Well I can for myself, but not for my 100 users. As this is a remotely exploitable resource leakage I think it should be backported.

  10. fafhrd91 commented on Mar 28, 2017

    @fafhrd91

    I mean fix should be included in library that you use. and sure it should be backported, but this will take some time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions