A proposal for ADCS and secure Direct Connect

I have thought about ADCS and how we can improve the world of Direct Connect, and the ADC network.
First, I looked over to see how DC++ ( and clones) create the certificates they use for ADCS connections. The certificate doesn’t seem to be signed, and it’s granted actually to that CID ( client’s unique id ).
I want to propose something about how to make this more secure for both hubs and clients who want to connect ( mostly clients who have certain rights on the hub ). This is intented to replace password-based login.
First of all, let’s start with a hub. After the hub is being set in normal ADC mode, the user needs to switch to ADCS. In this moment, the hub makes a certificate request to a CA [1], that temporarily grants him a certificate signed by this CA, hereby making the hub authoritative for it’s own users.

[1] : I propose the CA to be somebody of trust in Direct Connect, that can also monitor hubs and even revoke certificates for the hubs that don’t respect certain rules ( moral rules, the general direct connect rules…etc ). My first suggestion is a big hublist , with great influence ( these people also monitor hubs regularly ). Once the hub has this certificate from this CA, then users can connect to it safely ( It would be nice if clients could implement the CA’s public key and check the certificate’s signature, and at least warn users on login if the hub is not signed by the CA)

The second step of this thing is to create user accounts on the hub. For this, each client creates a public and a private key. The hub should be able to have an input for a client’s public key, and create a certificate for the client signed by the hub. This way, the client can login to the hub ( in which moment the hub checks if the certificate is signed correctly by itself ) and grant the respective user with all the rights given . No password needed, and the security greatly increases since the client’s private key is never sent anywhere so he’s the only one who can use the certificate, and only the hub who signed it can actually decipher it and accept it.

Hope this post is quite clear, I await some questions if not. I would also like something from hublist developers.

After talking to Flow, I’m not sure how important the CAs for the hubs are. Perhaps someone has a better idea.

4 Responses to A proposal for ADCS and secure Direct Connect

  1. quicksilver666 says:

    Certificates are something used with PKI systems …
    A CA is an institution that actually checks on a user if he is credible.. where he lives etc…
    Without a that checks certificates and the existence of a CA are more or less useless.
    It more or less seems only to generate a false sense of security for the users.

    In fact the result of using a CA in protocol will be that we are another step away from being a p2p system.
    By introducing a CA we will create a new instance that can be DoS-ed so DC becomes less usable. (Remember skype being down for more than a day? thats what central instances do to a p2p system)

    Additional, with a CA that has the power to inflict judgement on moral rules and doing that with the protocol not just with hublists sounds horrible.

    What comes next? Do we elect a Dictator that calls out TTHs of files that may no longer be shared? (Of course at start it will be only Kiddy Porn files, but may be IFPI will later get control over it)

    I think the target should be to get some sort of p2p mindset:
    Nothing should rely on any central structure that exists only once.
    If you want a CA in place let the hub be it for its user. If you want some proof that a hub is what he seems to be, use normal DSA or something to proof it. Shure without CA you can’t proof that some computer is the owner of a hub behind some DNS, but thats only important for the first connect. Its ok just to proof that you are now connecting to the same machine as the last time.

    On a side note. Don’t you think its kind of hillarious to talk about security baught by CA while there seem still to be known open buffer overflow problems ins DC++.
    It sounds like some company wanting to get more security by installing a firewall, but being unwilling to fix their sql injection bugs.

  2. pietry says:

    It was a proposal. It’s good that you have some ideas as well. About the buffer overflow problem, why don’t you speak it out so maybe it could even get fixed.

  3. quicksilver666 says:

    I don’t know how many are actually fixed..

    Though DC++ seems to have problems with long SR over tcp.
    Another problem I had is that, if after ADCGet some more commands are sent that also results in Buffer Overflow.

    When I wanted to tell developers about it I was told to never mind as these are already known now for Months/Years.

  4. poydc says:

    i’m not sure anyone knows about your security problem; otherwise, it would be in our bug tracker. feel free to open a bug there and explain what you mean…

    on DC++ not responding to all search requests, it will be fixed in the next version.

    in any case, DC++ is totally independant from ADC extensions.

    i agree with quicksilver666 on avoiding another centralized system.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: