ADCPortal the frontpage for Advanced Direct Connect

As some of you may know, ADCPortal is for some time a part of DCDev. ADCPortal provides the following for the normal user: latest news about the protocol and all the main software that is available on the market, ideas and comments about the future of the network ( what’s coming up and more ), information about all the protocol features including all the known extensions. One can also register and ask questions or propose his/her own extension.

ADCPortal also provides a full wiki that can be consulted to get all the required information about ADC.

The interested developer also has the opportunity to get in touch with the protocol designers and also people who worked around ADC, or created pieces of software for it.

We strongly encourage everybody interested in ADC to visit ADCPortal in order to get more information. Lately I heard that the main reason people are reticent about ADC is the lack of information. ADCPortal has been around for nearly two years, but people still wouldn’t come and ask. So please, come around, ask whatever question you like, don’t be shy, we will be very happy to answer you. We also hope you will find the site useful and we wait for you to join us.

Network of the future, next level filesharing

Today, file sharing it’s not just about you, me, or friends and the rest of the world. Files are not just streams of bytes anymore. They are representing us, in a way. Ever since telnet was used back in the old ages of networking, the need for sending files from one computer to another has increased exponentially.

DC++ offers a simple, plain way to keep your personal files available over the network. Some may say too simple, some may say it’s perfect this way. There are people who use DC++ and are happy with it, and some people who want more.

Let’s say I’m in both categories, I like using DC++ but also want more from it.

The current trending in file sharing is about social networking and metafiles. How can this be integrated into DC++? Well, I have some ideasand I want to point them out a little.

Files aren’t streams anymore, some are personal, like photos and movies, some are educational or informative, like documents , some are general purpose programs like a linux distribution. Each file could have a metafile attached to it. This way one could add basic information into tags, except the hash which is the sole metadata for now, like keywords or a picture. Size, description can be valuable information about a file, not counting it’s name.

Like this, one could search for keywords, can look at the descriptive picture and decide whether to download or not the file. In DC++, the file list could support this kind of feature. The list could be divided into categories ( pictures, video and so on ), each file could have a thumbnail, a description attached to it and some keywords, how many other people were interested in the file ( number of downloads ), or even a ranking system created by DC++ about the file. Searching can also evolve in this manner.

Social networking can be implemented more lively and can make file sharing an easy and pleasurable way of interacting with people and spending a nice time.

I certainly hope that DC++ will grow in this kind of features but also to support basic file sharing as it always did, simple, and easy to use.

DCDev goes ADCS

Since today, our public hub has moved from simple ADC to ADCS, aka ADC Secure. If you connected today and noticed that your client just printed out “Connected…” and that’s it, it’s because of that. You need to go to your favorites and change the address from adc:// to adcs:// , this means the DNS is the same, just the protocol handler changed.

So the hub address is now adcs://devpublic.adcportal.com:16591
You are welcome with suggestions, questions or whatever springs to your mind.

DC++ pointing out the corrupted

One of the latest enhancements in DC++ is the hub referral on client-client connections, proposed by Jan Vidar Krey. The current bazaar trunk implements this mechanism and the next DC++ version that will be released soon will also have it. The purpose of this extension is to point out the corrupted hub that is sending the current client to a non DC client, with obvious malevolent purpose. This implies that the hub is either using exploitable software, or that it’s intentionally abusing the clients. Either way, the hubowners are solely responsible.

On connecting to the other party, DC++ will also send the hub URL that it used to connect to the hub sending out the CTM message. By packet inspection, an attacked party can figure out which is the corrupted hub (only a pointer is required, such that they have a point of reference ) . Another good part about this extension is that it works on both ADC and NMDC ( some workaround was found for NMDC: adding the url to the PK string since NMDC is not extensible nor flexible in this matter ) , with the least effort from the clients and it does not bother them in any way. A normal client should ignore the specific message ( I don’t find any particular usage for it ).

We strongly recommend all mods to inherit this extension and other clients out there to implement it so the CTM attacks impact on DC software will stop being so great.

DC++ CTM Proof

In a previous post I was wondering if the whole concept of centralization is obsolete or has major flaws. The problem that is bothering everybody in the last years is that clients can be used ( unwillingly ) as tools in distributed denial of service attacks. Jan Vidar Krey is proposing a hub refferal on c-c connections that can point to a source of CTM attacks via the messages that the client sends on first connection attempt. In this case an attacked entity can see the hub with problems/intentional flooding that is causing the attacks.

As a first step to prevent this kind of abuses in DC++, poy added a static IP protection for the major hublists that were attacked via the client. This kind of measure is just temporary since hublists can change IP anytime and it protects only them, not everybody else that can be attacked ( Also the fun part is that the hublist server is actually running a DC client and wants to download from other users, it can’t ! ) .  A second step was to dynamically resolve the hublist ip’s and block them for c-c connections.

The main idea that I considered is to practically check all the users on a specific hub to see if they actually are real. On CTM receive the client should not connect but send another CTM to see if that IP actually connects to them . This will make sure that the user is the actual owner of that specific IP address. Of course the biggest problem is if the user is passive, in which case it can’t send a CTM back. This could be against the protocol principles but it’s a solution to see if the other peer really exists. I don’t know if a RCM would do something good in this situation but it’s a start.

Another thing that should be done ( if not implemented already ) is that on c-c connections if the first attempt was unsuccessful then no further attempts should be done until the user at least reconnects or changes state ( passive/active ). Also the hubs should be trustworthy. In a previous post I suggested a way to make hubs trustful via a CA authority system, but most people were quite reticent about it. Perhaps this could be the only way to make hubs trustful. Warning messages will not help too much ( Strong DC implements such messages ) since most of the users either don’t read them or don’t care. We shouldn’t let users question this problem, but solve it for them. Continuous problems from the Direct Connect network might be a cause to mark DC software ( and DC++ ) as badware, which will definitely take down the network. It’s time to do something about it.

I’m hoping for more ideas how to make DC++ proof against CTM abuses and I’m waiting for opinions from you as well.

Are centralized networks doomed from the start ?

Recently I heard bad rumors around the DC network. Some malevolent person ( unknown ) has written several scripts for the most known DC hub software, that allow the hub owners to use their users in abusive forms of flooding, using the CTM feature of the protocol. These scripts have started to spread around and now “script kiddies” use it for flame wars and endless childish attacks.

Also, important sites that currently hold on the DC community like the major hublists OpenHublist or DCHublist and the ADC counterpart ADCHublist were attacked and were down for a long time. The major community for ADC , ADCPortal was also attacked ( ADCPortal also provide an alternative wiki to the one on the ADC Project ).

My first concern is that this problem can spread up to the centralized networks principle. In this case, the central node ( hub ) has the power to absolutely control the leaves that are connected, thus it can abusively send them in possible attacks at wish. This might be a serious problem for the centralized networks.

Secure policies have to be enabled in clients and hubs so that this kind of flaws do not affect the community. I don’t know yet if it’s possible in this current situation or the whole concept of centralization is flawed. I hope not, because the Direct Connect community has it’s advantages and there are a lot of people involved and which benefit from it every day.

My advice from the users: make sure you actually know what hubs you are using, and how your client can be abusively used for other purposes than the ones designed, and make sure you are using a proper firewall and perhaps package inspection to see if your computer is not part of a BotNet or similar flooding network.

And one last thing, Happy new year and all the best from the DC++ team.

The 0 downloads crisis

Recently, I heard some shocking news about the Direct Connect network. Probably having nothing better to do, people are inventing conspiracies over nothing but grain of salts.

What I’m talking about is the SourceForge migration process that is happening right as we speak. During this process, the statistics for projects hosted by SourceForge are not being showed anymore. (They are being collected, but because of the undergoing modifications, they are not being printed ). What does this mean ? New file releases ( the process is undergoing for a month or so ) appear as if they have 0 downloads. Don’t worry though, files are being downloaded just like before. And after the migration is done, the actual download number will be updated with the real one.

People have seen in this a conspiracy : “Software like StrongDC or DC++ has a trojan ! The developers have included spyware, exploits ! That’s why nobody downloads them anymore ! ” Such kind of imagination would be really funny if such kind of things wouldn’t affect the normal people.

I would say that even if all the people in the world would agree that nobody would download DC software, there would still be a large number that would do. So for a project that has 10000 downloads a day, it’s impossible to have 0 downloads for a whole month just like that, over the night !

Also, the AVG anti virus reported the last version of StrongDC infected with some kind of Trojan, but the latest version removed the threat warning. At least they have repaired the problem.

So, don’t worry about your favorite p2p program being malevolent, because it’s not the case. People are working really hard to make a good program for you, because this is free and nobody gets paid, they do this just for pleasure. Why would anyone want to be discredited by intentionally adding an exploit or virus to the one program that made them famous around the community ?

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.

New address for DCDev Public Direct Connect Development Hub

The public hub is back up, the new address is :

adc://devpublic.adcportal.com:16591

We are sorry for the time it was down, and we hope it will not happen again too soon.

DC++ 0.706

Another version of DC++ is out. After 0.705 being stable, this version comes up with the primary fixes required by people on launchpad, and it’s getting closer and closer to the old interface functionality.
The most significant changes include :
You can now see if a hub/user is online/offline by the color of the icon.
The transfer color bars are back.
You can now share multiple folders under the same virtual name ( mixes the files ).
Every connection shows now on which hub it started.
Translations are more complete, we thank this way everybody who helped translating.
Among other multiple fixes, we hope this is the best DC++ version to the day.
The same thing goes, if no serious bugs are reported about this version, in two weeks it will be marked stable, so go ahead and download it from sourceforge and have a test. We await your feedback.