Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#180 Status Updates / Security Features

open
nobody
None
5
2012-09-28
2010-08-08
Matt West
No

So I was sitting back wondering if maybe a couple other features have the possibility of being implemented at all.

The first one I was curious about is also another hook option, I know that hash verification can take a few seconds to a few minutes depending upon how much data you are trying to push out. Is it possible to get a hook option after the verification has completed? I know that tailing the debug file would give me this, I was hoping to not have to build a logging dependency into my wrappers / hooks.

Second, is the ability to have a whitelist / blacklist tracker list. If I were to specify a group of trackers in the config file with say bt-tracker-whitelist then my client could then only connect to those hosts, as well as having the option to blacklist certain trackers, using bt-tracker-blacklist, that way I'm not connecting to places I feel are less than reputable. An example line would be bt-tracker-whitelist=http://example.com,http://announce.example2.com

Third, is the ability to encrypt the password stored in the config file for the xml-rpc-passwd. SHA1, MD5, something else besides plaintext would be awesome.

And finally, going way out on a limb, would be the ability to set a challenge password for all of my clients, that way if they didn't have / know the challenge password they wouldn't be able to interact with one another. This is just thought of as a way to implement some what of security mechanism for swarms inside of large environments.

I appreciate anything you could do with these ideas, I greatly appreciate what you have done thus far with the program; I'm finding it very useful and easy to leverage on a large scale. Thanks...

Discussion

  • tujikawa
    tujikawa
    2010-08-11

    Is it possible to get a hook option after the verification has completed?

    I think this has been already implemented. --on-download-complete hook is triggered after hash check.

    Second, is the ability to have a whitelist / blacklist tracker list.

    It is interesting feature. It can completely override trackers in torrent file.

    Third, is the ability to encrypt the password stored in the config file for the xml-rpc-passwd.

    Current implementation uses HTTP basic auth, so we need clear text password.
    It might be fixed conjunction with the forth issue.

    And finally, going way out on a limb, would be the ability to set a challenge password for all of my clients

    I agree that the challenge-response is a good idea for xml-rpc auth. Current HTTP basic auth is not secure at all. HTTP digest auth is well supported in many HTTP
    imlementation(aria2c does not support it though..), so it is a god candidate.

     
  • tujikawa
    tujikawa
    2010-08-14

    For security enhancement, while this may not be exactly what you mentioned, you can setup SSL reverse proxy and make clients interact aria2 through it.
    HTTP basic auth is insecure in plain HTTP connection, but with SSL proxy you can hide it from the public.
    By default aria2 only listens on loopback interface for XML-RPC control and with proxy in the same machine, clear text credential is only visible inside the machine.

     
  • Matt West
    Matt West
    2010-08-14

    I havent verified the first idea I had yet, but it seems reasonable enough that the program would perform that action... I hadn't thought about that but I will definitely look into it.

    The second thing would definitely be used to override the trackers defined in the torrent to ensure we didn't connect were we didn't want too... This would be a huge win in my eyes if this could actually be accomplished. Honestly I'm more interested in being able to specify only the trackers my clients can connect too (whitelist), but I thought the blacklist idea is a good catch at the same time...

    The third idea could probably be covered by the SSL Proxy proposal. It is an interesting idea for placing a more secure interaction method on the rpc port... I do have the xmlrpc port only listening on 127.0.0.1 for security purposes and setting up apache to be a reverse proxy is doable, I'll investigate this further and see if I can provide some feedback / howto...

    The fourth one I think we may be misunderstanding one another... What I was hoping for was to be able to put in a challenge password in the config, and unless the nodes in a swarm had the same challenge password specified in the config, they wouldn't talk to one another.

    With an environment as large as I'm trying to implement this in, there is the possibility that multiple swarms could live in the entire environment, and this would be a measure to just stop them from talking with one another unless I wanted them too...

    Thanks a bunch, have a good one...

     
  • tujikawa
    tujikawa
    2010-08-24

    Added --bt-tracker and --bt-exclude-tracker option. In
    --bt-tracker option, you can specify comma separated list of
    additional BitTorrent tracker's announce URI. These URIs are not
    affected by --bt-exclude-tracker option because they are added
    after URIs in --bt-exclude-tracker option are removed. In
    --bt-exclude-tracker option, you can specify comma separated list
    of BitTorrent tracker's announce URI to remove. You can use
    special value '*' which matches all URIs, thus removes all
    announce URIs.

     
  • Matt West
    Matt West
    2010-08-26

    Ok, so if I'm understanding what you've done here, I can add a * to the --bt-exclude-tracker option, thus blocking out every tracker, and then add a tracker to the --bt-tracker option and it will then only communicate with that tracker or trackers...

    If I have understood that correctly, that is great...

     
  • tujikawa
    tujikawa
    2010-08-26

    Your understanding is correct.