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.

Multiple shares in NMDC, revisited

Multiple shares in NMDC have been on topic for years, and will probably continue for years to come. Well, the current approach is simple; use a different port in each hub you’re in. So, if you’re in 5 hubs, the ports used will be (e.g.) 5000, 5001, 5002, 5003 and 5004 when using the CTM/RCM.

That this solution isn’t scalable haven’t bothered people to implement it. Patching a bad protocol does not make the protocol suddendly good. Oh well… People are free to implement away.

Encryption in NMDC, revisited

While cologic exhausted the encryption topic, I want to give a heads up in regards to TLS in NMDC. There are more and more clients that have implemented TLS in NMDC. The current technique is by specifying an ‘S’ in the end of the CTM (after the port, that is). Apparantly, YnHub and Ptokax (if I remember correctly, Verlihub, too) will not block this information and DC++ should be able to operate nicely when specified (even if it doesn’t support it).

Do note that NMDC encryption will not appear in DC++ (unless Jacek changes his mind, which is highly unlikely).

Decentralization in its inception?

An important part of the DC community is its ability to change and the ability of the developers to think of new and interesting ways to improve the experience that is Direct Connect. One important section of change is the posibility to take an existing program, like DC++, and change it to ones own liking. One of these clients is StrongDC++, which have features that are not in e.g. DC++ and some features that have migrated its way back to DC++.

A new exiting approach that can only be described as a way to extend Direct Connect is the ability to create a decentralized version of DC, using commands and functionality similar to ADC (and NMDC, albeit only insofar as the initial startup). The proposal have been made by, as can be noted by the page title, the StrongDC++ client and its authors (other people are as well involved).

Basically, the new protocol will be able to operate without a hub, and where one might still be able to share and download with others. However, it should be noted that to get a list of users, one need to connect to a hub and ask for other clients’ support for this feature.

(Note that I’m not saying that this will or will not be a feature incorporated in DC++.)

ADC hub referrer

In my Denying distributed attacks post, I described that users can be redirected to hubs. What I didn’t describe was whether there was a way for another hub to see if a user has been redirected or not. That is, something similar to the HTML referrer.

At the time, neither ADC nor NMDC had this type of functionality. However, before the official ADC 1.0 specification, a hub referral field was added to the INF.

What this means is that if a hub redirects a user, the client will automagically tell the hub so, when it successfully connects.

(NMDC still do not have this functionality.)

[If you’re not a hub (but eg a HTTP server) that’s being targeted, yes, you will need to do some communicating to find out from which address the user came from.]

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”

Restricting $ in file names

As of version 0.703, DC++ is able to share files containing “$” in their name. This is (obviously) because that restriction was removed. It was removed because it’s completely irrelevant at this time; DC++ will only use TTHs to request files. As such, it doesn’t matter if the file name is written in a special way (except maybe how it should be stored on the end computer, but that’s a different matter) when it comes to downloading.

All of this is now fine, but why wasn’t it previusly fine to share those types of files? Actually, this isn’t a restriction that has been set because the NMDC protocol didn’t support it; This is an artificial restriction in DC++. (Most likely because of its initial coding.)

You see, the NMDC GET command do require a $ in the command (besides in the beginning), but it’s not something a client couldn’t work around.

The command NMDC use is “$Get $|”. If the client start to search from the beginning (after “$Get”) after the $ to find the offset, a file name containing a $ will obviously break/behave unexpectadly. However, if the client would search backwards from the first |, it would be able to catch the correct offset and file name, even if the file name contain a $.

(Yes, of course, we still have a restriction for “|” in the GET and a file’s name.)

Note: I don’t know if DC++ has fixed this kind of behaviour for other commands still in operation in DC++.

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”

ADC’s client-client handshake

I previously wrote about NMDC’s client-client handshake sequence, and today I thought I’d talk about ADC’s handshake sequence.

As with the previous post, there’s going to be a client and a server that speaks, where the ‘client’ is the one that want to download and ‘server’ that one that’s going to upload.

For starters, the required commands are “SUP”, “INF”, “GET” and “SND”. The INF is going to contain the users CID, but I’ll use the same CID for both for simplicitly sake. [The both CIDs will still be the same size…]

(Note that the ‘\n’ is one character.)

Server
CSUP ADBASE\n

Client
CSUP ADBASE\nCINF IDWTFUTQBI4NT6MKTRT2EHSMGZM5H2BVM5IZD65FA\n

Server
CINF IDWTFUTQBI4NT6MKTRT2EHSMGZM5H2BVM5IZD65FA TO123456789\n

Client
CGET file TTH/PPUROLR2WSYTGPLCM3KV4V6LJC36SCTFQJFDJKA 0 -1\n

Server
CSND file TTH/PPUROLR2WSYTGPLCM3KV4V6LJC36SCTFQJFDJKA 0 12345\n

At which point the server starts streaming the file to the client. (The client will of course stop listening for the file when 12345 bytes have been received, and disconnect or send another GET. )

The server has sent 133 characters, or bytes. The client has sent 120 characters, or bytes.

This is pretty much what a normal client to client handshake sequence looks like. Note that the token (after the TO) is completely arbitrary. Also, the INF may contain more information; This is just what is required. I don’t see a point at the moment to send more stuff, but oh well…

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”

NMDC’s client-client handshake

As a continuation on the ADC vs NMDC posts, this post will discuss the client and client handshake under NMDC, and how DC++ has changed some parts of it.

First off, the following is taken from the old wiki, where the clients are using “RevConnect 0.668” (which I assume means that it’s based off of DC++’s 0.668 client part). Secondly, DC++ have deprecated the $Get and $Send commands in favor of $ADCGET and $ADCSND, which are ports from ADC.

There are two clients in this conversation. To simplify things, I’ll be referencing the clients as “client” and “server”, as ADC is using that, and I feel that that is more intuitive. I’ll be breaking things up in parts. The first part I’ll be listing what commands are needed to perform a proper C-C connection. The second part is “general” and apply to both ($Get/$Send and $ADCGET/$ADCSND), and I won’t repeat myself. The thid part will be a showdown with $Get and $Send versus $ADCGET and $ADCSND.

Okay. Let us give it a go. The commands that are required are;
“$Mynick user_nick”, “$Lock with_some_massive_block Pk=some_more_stuff”, “$Supports a_bunch_of_things”, “$Key some_nonsensical_thing”, “$Get filename_and_path$1”, “$Direction Download[/Upload] random_number”, “$Send” and “$FileLength the_file_length”. $ADCGET/SND comes in three flavors; (1) “$ADCGET file filelist 0 -1”, (2) “$ADCGET file TTH/root_tth_of_file 0 -1” and (3) “$ADCGET tthl TTH/root_tth_of_file 0 -1”, where the first gets the file list, the seocnd a file and the third the hash tree. Respectively; (1) “$ADCSND file TTH/root_tth_of_file 0 file_length”, (2) “$ADCSND file filelist 0 file_length” and (3) “$ADCSND tthl TTH/root_tth_of_file 0 amount_of_leaves”. (Note that the bunch of numbers you’re seeing are starting positions and stuff like that. Also, the “filelist” is shortened, because I didn’t feel like writing more here.) [Disclaimer; the $Key in the example will look like gibberish; I have no idea if it is. It’s what the wiki page says.]

Okay, now we know what we’re dealing with. Let us go through what we need to say to each other. The client is the one that want to download and the server is the one that’s going to upload.
Server
$MyNick server|$Lock EXTENDEDPROTOCOLABCABCABCABCABCABC Pk=DCPLUSPLUS0.668ABCABC|

Client
$MyNick client|$Lock EXTENDEDPROTOCOLABCABCABCABCABCABC Pk=DCPLUSPLUS0.668ABCABC|$Supports MiniSlots XmlBZList ADCGet TTHL TTHF GetZBlock ZLIG |$Direction Download 17762|$Key ……..A …..0.0. 0. 0. 0. 0. 0.|

Server
$Supports MiniSlots XmlBZList ADCGet TTHL TTHF GetZBlock ZLIG |$Direction Upload 6494|$Key ……..A …..0.0. 0. 0. 0. 0. 0.|

At which point both parties know that the client is the one that’s allowed to download since its $Direction random number is higher. At this point, the server has sent 208 characters, or bytes. The client has sent 210 characters, or bytes.

Moving on to the $Get and $Send part;
Client
$Get folder\filename$1|

Server
$FileLength 12345|

Client
$Send|

At which point the server starts streaming the file to the client. (The client will of course stop listening for the file when 12345 bytes have been received, and disconnect or send another $Get.)

The server has now sent 226 characters, or bytes. The client has now sent 239 characters, or bytes.

And now $ADCGET and $ADCSND;
Client
$ADCGET file TTH/PPUROLR2WSYTGPLCM3KV4V6LJC36SCTFQJFDJKA 0 -1|

Server
$ADCSND file TTH/PPUROLR2WSYTGPLCM3KV4V6LJC36SCTFQJFDJKA 0 12345|

At which point the server starts streaming the file to the client. (The client will of course stop listening for the file when 12345 bytes have been received, and disconnect or send another $ADCGET. )

The server has now send 273 characters, or bytes. The client has now sent 272 characters, or bytes.

Worth noting is that $ADCGET/SND will always have that 43 byte long TTH thing (except for file lists). On the other side, you might end up with a long path to the file you want, and $Get will get irritating. Also, $Get does not handle TTH leaves, so you’ll never be able to verify the data you’re downloading.

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”

ADC, not NMDC, can support multiple share profiles

NMDC cannot support multiple shares within a single client for the same reasons that it’s vulnerable to nick-faking; client-client connections cannot be unambiguously correlated. Identifying arbitrary client-client connections with the hubs from which they emanate is actually simpler than precluding nick-faking; any protocol which can prevent such an exploit, which requires characterizing not only the hub but the specific user, has the required machinery to allow unambiguous multiple share support. Because ADC can prevent nick-faking, it can also provide multiple share support in a manner unavailable to NMDC.

Whilst a protocol capable of identifying both user and hub can trivially identify a subset of that information and therefore the hub, which is sufficient for multiple share support, that doesn’t imply the converse of a protocol not identifying both the user and the hub being unable to identify just the hub, alternatively sufficient. However, when applied to NMDC and ADC the converse holds true. A gap between this claim and its converse would appear in NMDC having some mechanism capable of identifying hub, but not user. However, because in C-C connections, the sole identification of a nick is not hub-centric, but rather user-centric, such a gap mechanism does not occur. Therefore, one can reasonably conclude that no additional method beyond those previously discussed and dismissed exists within NMDC that would otherwise, after all, allow it potential ADC-level multiple share functionality.

Finally, though the CTM token of ADC has weaknesses, these are, both by contrast with NMDC’s client-client user identification weaknesses and in absolute terms, negligible. In particular, multiple users can collude across hubs to produce identical CTM tokens, and even sans such active malice, such a situation can by chance occur. However, multiple remote clients capable of cooperating to that degree might as well be treated as one client; indeed, a single remote client can behave arbitrarily whilst claiming a constant CTM token as well, so such collusion doesn’t actually increase vulnerability. The situation occurring by chance also fails to warrant substantial concern, provided a high-quality randomness source. This is an example of a birthday attack; the chances of such a collision remain negligibly small with at least 128 bits of randomness even with a large number of CTM tokens drawn.

As none of these weaknesses poses as substantial a threat to reliable identification of a C-C user with an identity derived from an existing hub as exists in NMDC, and indeed a negligible threat at all, ADC-based systems can well function to provide functionality that NMDC-based systems not only historically have not but theoretically cannot robustly and reliably provide, including multiple share support, resistance to nick-faking, and any other feature dependent on associating client-client connections with hub users.

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”

Nick faking in NMDC

The NMDC protocol contains several usability and security flaws which ADC fixes, including that of failing to unambiguously identify users to each other over client-client connections. As an example of its trivial exploitability under NMDC, this inability to cross-reference client-client and client-hub identifying tokens results in vulnerability to nick-faking.

This dearth of corroboration beyond a potentially ambiguous global nick ensures that no reliable way exists for a standard client to authoritatively confirm or refute a remote client’s ostensible self-identification, and thus to avoid nick-faking. At least four detection methods ameliorate but fail to solve this problem in NMDC: UserIP-based correlations, search result-based correlations, temporal correlations, and depending on the implementation, the simple expedient of asking someone whose nick is being faked if they’re responsible for a given C-C connection. None, however, suffice to create a reliable and secure P2P protocol.

Relying on $UserIP fails both in that no one-to-one mapping between users and IPs necessarily exists and that many hub-owners evince reticence towards distributing such information to users. Even were hub-owners more open to distribution of users’ IPs, or were one to trust nick/IP correlations derived from search results, multiple NAT’d users will appear from the same IP, meaning that though different ISPs imply different users, the converse remains untrue: the two connections having the same IP does not imply that they’re from the same user. These inherent issues with IP-based $UserIP imply continued vulnerability of NMDC, even allowed these methods, to nick-faking.

Not only do IP-based methods leave ambiguity, but intentional cheating, protocol innovation such as upload queuing, and even heavily lagged hubs similarly undermine useful dependency on temporal correlations. Traditionally, DC clients can know what what other users might connect to them because such connections generally occur in response to a $ConnectToMe message. Either a client seeks to upload or download. If seeking to download, standard procedure is to send a $ConnectToMe, which allows for the creation of a list of expected C-C connections which can dramatically narrow possibilities upon reception; if one’s sent a $CTM to user with nick X on hub Y rather than hub Z, then receiving an incoming C-C connection claiming nick X strongly suggests that one’s viewing the user from hub Y and not hub Z.

However, this still can fail – perhaps because hub Y hasn’t relayed the $CTM to the receiving user or because that user does not deign to respond by C-C connection to that message and sometimes because not all C-C connections occur in response to a proximate message at all. Upload queues, for example, can indefinitely delay a C-C response until when a slot actually opens up and thus break mechanisms depending on temporal proximity. Any of these alternative paths to a C-C connection break temporal correlation-based methods.

Finally, combining multiple techniques, including just asking the ostensible other user eliminates, does not eliminate this vulnerability, in the former case because they don’t, taken together, cover even the set of likely possible events and in the latter case because such manual intervention indicates a basic brokenness of a protocol. To find examples, just take the intersections of the sets of counterexamples of each technique, since they operate basically orthogonally – an upload-queuing user behind a NAT breaks both. One can appeal to manual fixes in response to arbitrary protocol flaws – taken to its limit, one can run a DC-like system entirely manually. As such, suggesting to use that tactic is a non-response.

Whilst none of these fixes reliably fixes NMDC, ADC robustly avoids nick-faking in client-client connections by use of the CTM token.

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”