python-tuf: Reinstate full protection against slow retrieval attacks

Description of issue or feature request:

#781 updated tuf’s downloader module to use requests instead of custom networking code, to fix issues with HTTPS proxies.

This change, however, deprived TUF of a way to prevent a certain kind of slow retrieval attack, where the attacker sends bytes below a minimum average speed.

This attack can not be prevented with the timeout parameters provided by requests, which are:

  • connect timeout (max # of seconds to establish connection with server)
  • read timeout (max # of seconds between bytes sent from the server)

Current behavior: Cannot reliably enforce minimal average download speed and thus is vulnerable to slow retrieval attacks.

Expected behavior: Reinstate full protection against slow retrieval attacks

Possible ways of fixing are

  • report issue to requests and ask them to fix it, or
  • switch to equally well-established and feature-rich requests-alternative that supports non-blocking I/O

Note: The comments in #781 have more ways of addressing this issue and also discuss whey they are not viable. Consider reading up on the discussion when working on this issue.

About this issue

  • Original URL
  • State: open
  • Created 5 years ago
  • Comments: 15 (11 by maintainers)

Most upvoted comments

Btw., (and this is more a note to the co-maintainer) I saw that none of the mentioned libraries work on Python 2.7. @SantiagoTorres, @trishankatdatadog, @JustinCappos how long do we still want to support a Python 2.7 client?

I think this is an artifact of async not existing on py2 (iirc). My ideal roadmap was to:

  1. Provide library X as an optdepend
  2. if exists, you get slow retrieval protection
  3. if it doesn’t, then you get whatever is in place right now

I find this appealing because we can also allow people to fall back to the default implementation if they find things to be finnicky. Needless to say, this way we can also leave py2 out of the question.

Hey @lukpueh, I would also love to work on it as part of GSOC2020. Currently finishing my proposal and going to send a post in Slack.

I’d like to grab this, though it may be a a couple of weeks until I get round to it.

Many thanks for putting this together, @jcstr! python-aiohttp indeed seems to be the most popular choice of the 3. It might be worth comparing it to the seemingly similarly popular httpx in regards to code readability. Easy-to-read code is a key requirement for the TUF reference implementation!

Also, I wonder which of the key features you mention above you intend to use for this task. Can you explain why all of these are relevant?

At any rate, I’m looking forward to seeing proof-of-concept example. How is that coming along? Any code to share?

Btw., (and this is more a note to the co-maintainer) I saw that none of the mentioned libraries work on Python 2.7. @SantiagoTorres, @trishankatdatadog, @JustinCappos how long do we still want to support a Python 2.7 client?