DC++ is 20 years old today

In the beginning there was NMDC, as its name says (Neo-Modus) a new way of file sharing. It was a quite good, if not revolutionary idea of its time but a bit clumsy and low-quality implementation of a business model that wanted to get revenue through displaying ads in its client software. NMDC could be used for sharing of files using a community hub capable of controlling direct file transfers between its online users and also relaying searches and instant messages. This system of direct file sharing built around online communities has quickly become a success at the end of the 90’s, despite its clumsiness and annoying limitations.

The early years

In the fall of 2001 one DC user, a secondary school teenager, thought he could easily make a much better, ad-free client for this network and that it would would be a fun project for him to improve his skills in C++ programming. So DC++, an open source replacement of the original Neo-Modus client has born, exactly 20 years ago this day. And the rest is history…

DC++ had rapidly become a success. Many users switched to it and enjoyed the new intuitive interface, the slick and fast look-and-feel, the new thoughtful functions like the ability of connecting multiple hubs in parallel. Neo-Modus had put out a new versions of its client as an answer, trying to amend the limitations of the original one but the effort was completely futile – by that time DC++ had already become the go-to client for the DC network.

As it happens with most open source development, with time, contributors appeared and helped to add their ideas and fix bugs in DC++. Many of them just came and went but some remained, giving more and more input and help for the original author to make DC++ better and better. Somehow, the changelog of DC++ preserved some of what that early development was like, it is a fun to read from the distance of so many years, especially for those who hadn’t been around DC that time.

But not all of those outside ideas and directions were accepted to DC++. Many people wanted to go to different ways and this can be easily done in open source; soon, there was no shortage of various forks of DC++, some existing just for the sake of a few additional functions while others went much further, to different directions adding complete set of new features and optimizations. But, with the exception of the few examples, most of them were still built around the code provided in DC++ as a base. Many forks were short-lived, having been abandoned within months or years but a few ones are still remained being developed or at least maintained these days.

These were the years when DC as a file sharing network flourished; public hubs with overall usercount in the hundred thousand magnitude and also a lot of smaller private communities.

On the pinnacle of file sharing

Once DC++ achieved the initial target of being a fast, full-featured, easy-to-use NMDC replacement, it was time to improve the initial system created by Neo-Modus. The protocol (1), (2), connections, file transfers were insecure, especially the latter; file identification and corruption problems were an everyday thing in DC. For example, files were identified by their names and sizes only so searches for other sources for the same file many times came up with another file of the same size, resulting a corrupted download.

This needed to be fixed and the fix came in the form of Tiger Tree Hashes that allowed the files to be properly identified, searched and verified after download so no corrupted or arbitrary content would arrive anymore to your computer. It’s still the same today; it comes with the need of hashing files before sharing, but it provides the ultimate safety and integrity. Some users and forks hated hashing and stayed behind – eventually, DC++ has become incompatible with these old clients and their stubborn users.

Interesting part of the story is that before the old ways of transfers without hash check is finally removed in 2006, the team has released DC++ v0.674, a version that’s become quite popular among large group of DC users – so much that even today it is still the most widely used old version of DC++ among those stubborn people mentioned above. Yes, this version was moderately stable at the time, an end result of an era in the development of DC++, still compatible with the old hashless ways. And since big changes were coming in the forthcoming releases, this one remained known as “the best” and “working” DC client for many. Nevertheless, DC++ 0.674 has soon become less and less secure and by today plenthora of vulnerabilities has been discovered in it. Also, being developed on a different era with the tools of the time, it isn’t that stable running on modern Windows versions, either. Our favorite support requests are when people demand to fix these instability issues on a 10+ year old version of the program when even most of the tools that used to build DC++ back then aren’t working anymore on operating systems of today. Of course the fix is available long time ago, only a version upgrade away.

Still leading the way to be secure

In the meantime, DC’s decline started to happen as in the middle of the 2000’s torrents became popular. The development of the Internet as a whole and the way torrents work fitted better for many file sharing users. In torrents, related group of files were bundled and client software were easier to set up and use, community members not needed to be online with a client software anymore to communicate with each other as messages were persistent on the web. IRC could be set up and used for those who missed instant messaging so this was a suitable replacement of earlier file sharing methods for many.

Yet the author of DC++ had his next big thing to realize. A complete change of the old commmunication protocol of DC, inherited from Neo-Modus, to a brand new one that is professionally designed, defined and documented; a standard protocol that is secure, aims to fix the design issues of the old one and is extensible with features, most notably with support of secure encrypted connections. The new protocol was named Advanced Direct Connect (ADC) and the first draft has been released in 2006. In parallel, with the help of many contributors, elements of the new protocol had been started to built into DC++ and also into its forks.

Thanks to ADC, by the end of the first decade of the new millenium Direct Connect was ready for the change to become a fully standardized file sharing system with safe and secure encrypted communications. Yet ADC has never taken off, really. Partly because it has came too late and the focus of file sharing has already moved elsewhere, partly because the reluctance of members of the DC network: key hub software developers, hub owners and hub list server maintainers. Many new ADC hubsoftware started to appear, written from scratch, some were just hobby projects while others showed promise and were high quality software. Since the DC network was reluctant to adapt to ADC, most of the new hub software were abandoned soon, and by now only a few that are still maintained. ADC has become popular only within small private DC communities due to its security and advanced integrity.

From development to maintenance

By 2008, DC++ had completely switched to free, open source build tools and libraries, not to rely on closed products of big tech companies. Meanwhile, inputs from the original author of DC++ started to phase out and eventually completely stopped. Under the control of a new leading developer DC++ had started to catch up with other DC clients in user-friendliness: new graphical UI elements, modern look-and-feel, easier setup and complete documentation of UI elements and functions, plenty of new functions like automated connectivity setup, secure encrypted private messages between users and so on.

And then, after a few years, the constant development that had characterized DC++ in its first 12 years of existence, just ended abruptly. In the following years DC++ had been slowly switched into maintenance mode, with mostly essential security and small bug fixes added to each release. Some other DC clients are still improving – changing and adding features to DC in their own ways but, at least to this point, remaining mostly compatible with DC++.

And this is where we are at today, 20 years after the start.

These above just semi-randomly picked important parts of the whole story. There were ups and downs, problems and solutions, you can find many more piece of the puzzle (mostly the technical aspects) throughout this blog. But the things mentioned here today are enough to show that key people created and worked on DC++ had been the most influential ones on the development of the DC network, at least in the best part of the last two decades. And while by now others shaping DC, almost everything is still based on the work of the people who have been in and around DC++ in these years.

And all the contributors to DC++, both ones who realized plenty of big ideas and ones with just small additions, they’ve done it mostly for having fun and to learn new things, improve themselves. They were many – you can find all the names preserved in the About box of DC++.

DC++ is still somewhat popular these days, around 10k people still interested on it in a course of a month. The program is still maintained, albeit in a slower speed and no ambitious feature updates in the plans. People remained with the project want to provide the safety, stability and compatibility and want to make sure that DC++ at least remains viable for some use cases. Hopefully, this will help users to keep having fun using DC++ for many more years.

Happy birthday DC++ and keep on sharing!

DC++ 0.870 is out

Later is better than never, years after the release of the previous version, a testing version of DC++ 0.870 is now available with various library updates for security and stability, mandatory TLS 1.2+ support, revised selection of public hub lists, fixed GeoIP country display and numerous bug fixes including one that has been present for at least 15 years.

The following are the most important, user observable improvements:

  • DC++ 0.870 and later will require TLS 1.2 or newer (currently only TLS 1.3)-based ADCS connections to hubs and other clients. This has already been announced before and is now done with this release.
  • GeoIP files aren’t deleted after an unsuccessful download and thus does not leave the user without GeoIP data for the session. The country data display in the Transfer View and Search window is also fixed.

The list of complete changes for this new version are available here.

This release has gone through the usual testing cycle and should be marked as the new stable release within a few days.

Updating and using the newest, most secure DC clients is always important so users who want to give the new release an early go can head over the DC++ download page and do the upgrade now.

DC++ 0.868+1 will require TLS 1.2 or TLS 1.3

In accordance with the published plan, the next DC++ release will increase the minimum supported TLS version from 1.0 to 1.2. This follows Firefox, Chrome, and Fedora doing so as well. As DC++ 0.868 supports TLS 1.3, DC++ will, for ADCS, use only TLS 1.2 or TLS 1.3. Additionally, client-client connections for ADC hubs will default to requiring TLS, also 1.2 or 1.3.

Widely used, currently maintained DC clients interoperably (Russian original) support TLS 1.3 in this manner as part of ADCS, as Delion’s post documents, including DC++ since version 0.868, ApexDC++ since version 1.6.5, AirDC++ since version 3.53, EiskaltDC++ since version 2.2.10, FlylinkDC++ since build 21972, and ncdc.

This DC++ release will, due to practical and efficient chosen-prefix SHA-1 collisions, similarly disallow SHA-1-based TLS ciphersuites. Remaining ciphersuites provide forward secrecy.

Finally, enforcing Diffie-Hellman keys of at least 2048 bits avoids the previous 1024-bit DH keys vulnerable to well-funded actors, and likely already broken by nation-states to which ADCH++ had defaulted.

Dropping less secure TLS versions 1.0 and 1.1, along with SHA-1-based ciphersuites and weak DH keys, protects DC++’s and the DC network’s security against current and emerging cryptographic attacks.

DC++ 0.868 is out and marked as stable

A year after the previous version, DC++ 0.868 is now available with various library updates (notably OpenSSL 1.1.1 with TLS 1.3 support) and a revised selection of public hub lists.

The list of public hubs came with the client has been pretty much outdated for some time. A few previously listed servers are already defunct while some are changed their web addresses. Therefore a refreshed list of secure and working hublist servers was long overdue. Many of such new public hublists will get auto-added to your collection upon the update to version 0.868 due to a change of policy regarding hublist server defaults. In the past a change of default hublist servers were not reflected in the actual settings – you had to remove  all existing server entries manually to get the updated defaults. This method, being deemed a bit cumbersome, has changed; in this release the addition will happen automatically and it will be the same in case of any future changes as well. A “Reset hub lists” button is also available in the settings should you want to quickly clean up the list of servers and get back to the defaults.

With the OpenSSL library update, DC++ 0.868 introduces support for TLS version 1.3 and is automatically preferring this newest secure communication standard when connecting to other DC clients and hubs. Backwards compatibility to the earlier versions of the protocol is decided to be maintained, similarly to most of the modern popular web browser software, until at least 2020.

Above the aforemntioned feature updates this is a maintanence release, with a few small updates here and there. There’s also a feature removal: support for the long defunct (and often criticised) Coral CDN network ended with this version.

Due to the useful features and security related fixes an immediate upgrade from earlier versions of DC++ is highly recommended.

 

Disabling TLS 1.0 and 1.1 in DC++ by 2020

Following the IETF’s deprecation of TLS 1.0 and TLS 1.1Chrome, Edge, Firefox, and Safari have announced that they’ll disable both TLS 1.0 and 1.1 during the first half of 2020. GitHubStripeCloudFlarePayPal, and KeyCDN have all already done so on the server side. The deprecated TLS 1.0 dates from 1999 and TLS 1.1 from 2006.

Meanwhile, TLS 1.2 has now existed since 2008 and been supported by OpenSSL 1.0.1 since 2012. DC++, along therefore with modified versions, has supported TLS 1.2 since version 0.850 in 2015. ncdc likewise has supported TLS 1.2 for many years. ADCH++, uhub, and Luadch all support TLS 1.2 or 1.3.

Hardening DC++ Cryptography: TLS, HTTPS, and KEYP and BEAST, CRIME, BREACH, and Lucky 13: Assessing TLS in ADCS document vulnerabilities that TLS 1.0 and 1.1 allow or exacerbate, including but not limited to BEAST, Lucky 13, and potential downgrade attacks discovered in the future in TLS 1.0 or TLS 1.1 to which TLS 1.2 is not subject.

As such, DC++ has deprecated TLS 1.0 and 1.1 and will disable both by default in 2020 along with the browsers, while supporting TLS 1.2, 1.3, and newer versions, with an option to re-enable TLS 1.0 and 1.1 should that remain necessary.

DC++ 0.867 is out – Vulnerability disclosure

DC++ 0.867 has been released and also marked as the stable release. It fixes a serious remotely exploitable vulnerability that would crash the client if a malicious attacker sends trivially compilable malformed search result messages.

The victim should not need to initiate searches and the attacker should not need to be logged on to a hub for a successful exploitation altough the obvious place for finding victims and collecting attack surface information are the DC hubs.

Clients configured to a working active connectivity mode are the easiest targets, especially when logged in to any kind of Direct Connect hubs. Theoretically exploits can be created for clients running in passive mode, too, using possible additional weaknesses in various hub software.

The vulnerability seems to be exist as far back as in version 0.671 (released in 2005) and in all newer releases up to DC++ 0.866. Many other DC clients based on dclib, the core library of DC++ and released over the last 12 years should be vulnerable, too.

The vulnerability report and detalis are now publicly available in the DC++ bug tracker. Updating and using the newest, most secure DC clients has never been more important so the best everyone can do is to head over the DC++ download page and upgrade as soon as possible.

DC++ 0.866 goes stable – Vulnerability disclosure

DC++ 0.866 has been marked as stable today. As it was announced before the new version fixes a serious denial of service problem that can be relatively easily triggered by any malicious user of any hub running without defenses applied.

In short, a specially crafted main chat or private message consisting of large number of empty lines can make older versions of DC++ completely stop responding.

Details of the vulnerability are available in the original bug report entry.

The bug causing this problem exists in all versions of DC++ between 0.760 and 0.865.

Above the client update requirement, hubs can relatively easily mitigate this problem by disallowing any hundreds or thousands line long main chat and private messages to be (repeatedly) sent through the hub.

Since there’s no guarantee of proper hubside defense against this bug being implemented on all connected hubs and the vulnerability can also be exploited by sending messages through a direct encrypted private message channel, we strongly recommend all DC++ users to upgrade to the latest release as soon as possible.

DC++ 0.866

DC++ 0.866 is out. This release fixes a serious issue that allows remote denial of service attacks (ability to freeze the client remotely by any user of the connected hubs).  Besides the hardened security, version 0.866 also improves UPnP port mapping which might fix certain issues with the automatic connectivity setup.

The details of the vulnerability will be disclosed as soon as 0.866 or any forthcoming DC++ release is marked as stable.

DC++ 0.865 is out and marked as stable

DC++ 0.865 has been released with zlib and OpenSSL libraries have been updated. The compression issue found in the previous version has been fixed therefore upgrading to version 0.865 is highly recommended.

DC++ 0.864

DC++ 0.864, along with changes in share filtering and an addition of testing notifications, fixes a stability issue regarding processing of search results. The issue is introduced in the previous release so immediate upgrade for users running version 0.863 is highly recommended.

Edit:

Tests with the 0.864 version of DC++ have uncovered a transfer issue (see https://bugs.launchpad.net/dcplusplus/+bug/1656050) so the release has been removed. It never made it to the “stable” status.

Please keep using version 0.863 for now.