A new proposal for a more secure Direct Connect

Site Announcements
Pietry
Senior Member
Posts: 328
Joined: 04 Dec 2007, 07:25
Location: Bucharest
Contact:

A new proposal for a more secure Direct Connect

Post by Pietry » 03 Jun 2008, 17:51

Hi. 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 thingy 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 Crise for the client part and netcelli/Catalin for the hublist part.

I'm in the disposition of implementing all this in DSHub for the hubsoft part.
Just someone

Toast

Re: A new proposal for a more secure Direct Connect

Post by Toast » 04 Jun 2008, 15:16

The big question is who should run a service like this ?

Well my vote is on hublist managers.

DCHublist and Hubtracker are the current up to date hublists.

Well DCHublist more then Hubtracker since they are banning old software that support CTM Exploits (Sorry Catalin).

Here are some thoughts about ethical rules for a CA
  • impartial
  • Updated on DC Standards/Flaws *(ex. Exploits view notes below)
Note: the CTM Exploit and other exploits known on Direct Connect should be protected against not every hublist yet thou (too bad).

Reasons for banning a hub as a CA
  • 1. Destructive Behaviour towards Direct Connect Community*
    2. Used for Faking
    3. Used for spreading illegal porn
*note: Thinking of the recent events of hublist.org when it was taken out of commission and left 10000 of users stranded looking for hublists.

There for a failsafe method should be implemented also so this cant happen to adcs CA's

Spookie
Junior Member
Posts: 19
Joined: 05 Dec 2007, 16:40

Re: A new proposal for a more secure Direct Connect

Post by Spookie » 04 Jun 2008, 15:28

This is a intresting idea.

I will wait for more information from hublist/client devs before I put my vote in for who should manage this.

Toast ideas about rules/banning/security is good.

Spookie

Pietry
Senior Member
Posts: 328
Joined: 04 Dec 2007, 07:25
Location: Bucharest
Contact:

Re: A new proposal for a more secure Direct Connect

Post by Pietry » 05 Jun 2008, 09:58

Anyway, there shouldn't be just one CA. Having more it's more failsafe and people can choose who to trust.
( Users could trust the hublists they already use in their client, when the hublist per se is being downloaded, the client could also grab the hublist's public key if it doesn't have it already , so it can check the certificates signed by this hublist )

A hub signed by dchublist.com ( example ) should be more trustworthy than a hub signed by myshittiehublist.com ( example )
Just someone

Kryppy

Re: A new proposal for a more secure Direct Connect

Post by Kryppy » 06 Jun 2008, 08:01

Very interesting , but how to improve basic users to use it ?( i mean that when it will be ready , the user's shouldnot understand the benefits and the use of it)

Toast

Re: A new proposal for a more secure Direct Connect

Post by Toast » 06 Jun 2008, 08:22

Well thats up to hublists and hubsoft developers and client developers

Perhaps someway to clarify it for the common user

like upon login a msg appears that verifies that it is a secure hub and a short explanation.

Clients could mark secure hubs in another color separating them from the rest

Image

Too bad that more developers hasn't commented yet on this thread.

Pietry
Senior Member
Posts: 328
Joined: 04 Dec 2007, 07:25
Location: Bucharest
Contact:

Re: A new proposal for a more secure Direct Connect

Post by Pietry » 06 Jun 2008, 10:50

A client could post a green check sign when connecting to hub and some message in the status bar like :
"This hub is signed as safe by blablahublist.com"
or a red exclamation mark with :
"WARNING: This hub is not certified by any hublist, your experience may be different, even dangerous"
Just someone

chaos

Re: A new proposal for a more secure Direct Connect

Post by chaos » 09 Nov 2008, 17:42

It's an interesting concept that you have here. Sorry for my late input on this. A couple of considerations though. Yes dchublist.com is trying to take a stand against exploitable hubs, it has its downfalls as you can imagen but thats life. We are not just simply banning their hubs though we are just refusing to list them in the client list or online list of the website. They are still managable and the owners have the option to update in order to reactivate.
We would be happy to digitally sign hubs but this technology must be based upon existing technology not something we ourselves will devlop otherwise there is likely to be disagreements and arising issues. One thing I dont particiluarly want though is a key edition to the hublist formatted file, this data should be stored elsewhere... when your serving well over 150,000 client lists per day... adding several bytes or even kb's to the list size can have quite an impact on resources not just for us but anyone else who wishes to implement such a feature in the future.
I do disagree with something though. The rules for a digitally signed hub. U mentioned the exploitable hubs could not be digitally signed which is a given as no issuer would sign a hubsoft version that can be exploited. But in terms of the content the hub has, this is a sticky subject. Half of so called 'bad porn' on the net is just filenames comprised of many bad keywaords for maximum exposure, doesnt mean its actually bad porn. And what content a hub hosts is nothing to do with hublists, its the owners and ops of that hub that need to regulate it. We as a hublist can only categorise the hubs content not pass judgement based upon it.
So what exactly will make a hub certifiable? I think thats a tougher question then previously thought of ;)

Pietry
Senior Member
Posts: 328
Joined: 04 Dec 2007, 07:25
Location: Bucharest
Contact:

Re: A new proposal for a more secure Direct Connect

Post by Pietry » 09 Nov 2008, 18:19

Since this was posted, my thoughts have changed a little bit. Indeed, it would be a too great risk of subjectivity and/or centralization minuses. However, the hub signing the clients stands. And the hub will be signed by itself. In this case the user can tell if the hub has changed since his certificate will no longer be valid ( being signed by the hub's private key ) , so masquerading will not be possible. And you're right about the content of the hub, that's a subject of too much subjectivity.
Just someone

adimosh
Newbie
Posts: 4
Joined: 15 Aug 2008, 21:23

Re: A new proposal for a more secure Direct Connect

Post by adimosh » 30 Nov 2008, 09:07

My (very very late) input on this:
- having no centralized and recognized authority/authorities will add absolutely nothing towards the DC community. It's like Mozilla or IE accepting by default any type of certificate issued by any type of CA. In that case, there wouldn't be any purpose in having CA-s. If you really wish to do something about it, do it the way it is currently done in commercial software: have official CA-s and allow independent CA-s. That way, a user will see "This hub's certificate may not be valid because: The certificate was not signed by a trusted certification authority. If you trust this authority (www.certificationauthorityfordummies.com), please click here to add it to your trusted authorities list." ... or something like that ...
- keep in mind that centralization doesn't mean unity of operation; having one standing CA doesn't mean that it cannot be spread along a larger community, in terms of operation; that way, redundancy is ensured: one falls, the rest still stand, and with clever-enough web development, it is possible
- for the moment (since ADCS is somewhat of a novelty), why not allow hubs to generate their own certificates, as Pietry said?

However, I do have a question: how exactly do current hub software and current clients communicate the certificate(s) one to another?

Locked