Vulnerability disclosure: remote code execution in Scripting Plugin

A new version of the Scripting DC Plugin has been released today fixing a serious vulnerability that allows attackers to remotely execute any code in the host system running any DC client compatible with DC Plugins, such as DC++. The nature of this vulnerability can cause various security issues, for example it makes the attacker possible to aquire any files from the host’s mounted filesystems.

For successful exploitation, Scripting Plugin version 1.0 should be installed AND enabled in any DC client / versions that support DC Plugins. DC clients having this particular plugin not installed (or installed but as long as the plugin is in disabled state) are NOT vulnerable.

For users running Scripting Plugin version 1.0 it is highly recommended to upgrade to version 1.10 as soon as possible to get protected from this vulnerability.

Please note that a vulnerable function named LuaExec has been completly removed from the plugin’s scripting API and that this release also updates the internal Lua engine to the latest version, both of which changes may cause incompatibilities with existing customly created Lua user scripts.

We’d like to thank RoLex of Team Elite for reporting, sharing proof of concept and recommending fixes for this issue.

DC++ 0.881 is out

A new DC++ release has been made available to download this week. Version 0.881 continues to be a largely code maintenance release, however, this time it also comes with some improvements on the user interface as well.

First and foremost with this release DC++ is moved to a modern compiler platform that produces an executable that shoud be considered secure and acceptable by modern Windows versions long term, with their default security settings. Since these defaults can change and go stricter at anytime it is highly recommended for users running Windows 11 to upgrade their DC++ to version 0.881.

There’s also a revamp of many icons throughout the user interface which makes DC++ more fit visually to modern Windows themes. An away status indicator overlay is also added to the taskbar icon. The look of the list of users and their details in the Users window has been modernized as well; more of this kind of improvements to come in the next release.

The optimized (64-bit) build is now compiled with use of SSE4.2 CPU instructions making further improvements in performance for those with capable hardware. We still provide a legacy (32-bit) build for users with older computers.

Plenty of supporting libraries that DC++ has built in have also been upgraded to the latest and greatest versions, improving security and stability.

There are also many less important or unlisted improvements; for a complete list of fixes as always please refer to the changelog or the list of commits.

As usual, the availability of this new testing release will be advertised at the start of the program for a small set of the userbase from now. If no bigger problems are reported, DC++ 0.881 will be set as a stable release within a few weeks.

DC++ 0.880 is out

The first DC++ release that brings a few notable changes since last fall’s version 0.870 has been made available to download this week. Version 0.880 marks the start of a new era, an active maintenance mode if you like, that we announced roughly a year ago. Along with that line there are no new significant functional improvements to be expected in the foreseeable future – we focus on possible speed and resource optimizations, bug fixes, compatibility as well as to keep the program up-to-date security wise. So finally you get the first pack of those improvements with DC++ 0.880.

Here are the most important changes, the already announced ones listed first:

• DC++ is being released under GPLv3 from now.
• Binary distributions split to optimized and legacy with according hardware requirements
• Used a new updated compiler version for better performance that allowed optimizations for speed, compatibilty with modern Windows versions and more.
• This version introduces a new stable hublist server.
• Fully restored the use of an up-to-date GeoIP country database service, the one allows you to see what country a DC user is from, determined by their IP address. Country info display was absent or has relied on a pretty outdated static database in the last few years so this goes back to normal from now.
• Hublists caching have changed according to the joint proposal of all hublist server owners: downloaded cached lists are set to expire in 24 hours from now by default. But this simple method alone would break the original purpose of the hublist caching function which has been introduced years ago to help users finding public DC hubs when hublists providers are out of service. So now we implemented a change with the original purpose in mind: cached lists are deleted only if a hublist refresh is successful. When a hublist download attempt fails or the resulting list is invalid the proper cached copy of hublists are being kept (even indefinitely e.g. when the source server is discontinued).
• Added a safeguard to attempt outgoing ADC connections on IPv4 only if there’s no IPv6 connectivity available. So far this decision was based only on information coming from hubs which, in case of improper IP address information supply, could break transfers and searches in DC++. There is at least one ADC hubsoftware that has such a buggy behavior triggering the issue so this change actually fixes existing problems already experienced in the wild.

There’s also a few less important or unlisted fixes improving security, stability and usability; for a complete list of fixes as always please refer to the changelog or the list of commits.

The availability of this new testing release will be advertised for a smaller set of users who are running the latest stable release of DC++. If no severe issues arise, DC++ 0.880 will be marked as stable within a few weeks.

DC++ license change

A quick but important notice: from version 0.880 (release imminent) and on DC++ will come with General Public License version 3. The license upgrade has been done with the written approval of Jacek Sieka, the original author and copyright holder of DC++.

This change is important for the future maintainability of DC++ since some external data sources and (future versions of) libraries (will) require a compatible license. The change should be equally important to projects using code from DC++ for the same reason.

DC++ 0.880 will introduce new build names, require SSSE3

DC++ has already introduced CPU opcode feature requirements in the past when those features were widespread enough in various PC hardware the program had been used on. We already require SSE3 since DC++ version 0.863 and SSE2 since 0.861. They have brought siginificant advantages and optimizations to the code as you see in the linked posts in detail. We added those optimizations carefully back then, knowing all the features in case had been already widely introduced in all CPUs manufactured in the previous 10 years or more so it shouldn’t have caused issues for the vast majority of users who care to keep their system and software up to date.

The obvious step forward is to require SSSE3 to gain more advantages but there’s a caveat: while Intel introduced this feature in its client CPUs in 2006, AMD has added it only surprisingly later, in 2011. Aging of PCs are knowlingly slowed down in the recent years so requiring this feature would make the latest versions of DC++ unusable on many old but still working PCs and we’d like to avoid that. At the same time, if we decide to require at most ~10 year old CPUs now then we can go much further with optimizations as there are plenty of other new CPU opcodes are supported by the processors that has been manufactured in this timeframe.

Therefore we decided to make a difference in optimizations between the two available builds of DC++: the 64-bit build, named “Optimized” from now, will require a CPU that is manufactured in the last 10 years going forward whereas we plan to make the 32-bit build (now called “Legacy”) remain usable on pretty old (currently 15+ year old) computers and 32-bit client editions of Windows. We plan to release this build as long as there’s some form of official support of 32-bit Windows editions exist.

As a first step foward the Optimized build of DC++ 0.880 will require an SSSE3-capable 64-bit CPU, which is basically anything newer than Core2 from Intel and FX series (Bulldozer architecture) from AMD. We plan to add more feasible CPU opcode optimizations in the subsequent releases of DC++.

This also means that from version 0.880 and on, users running 64-bit Windows versions on older, non-SSSE3-capable hardware will have to use the 32-bit Legacy build of DC++, even on 64-bit CPUs.

We added an automatic, completely seamless mechanism to the installer of DC++ that decides what build is best for the users’ system and that will be offered by default in the options at install time. Those, however, who like to use the portable releases have to be cautious. We’ll update the informative readme file in the download folders for help the decision of what build to download.

We release these two builds from now as predictably there would be not much demand for 64-bit releases targeting older CPUs, even less for 32-bit ones targeting newer processors. However, if you’re in this unlikey situation for some reason then do speak up in the dev hub and your request won’t be denied.

ADC? No, cancelled…

Back in the end of 2000’s when the 1.0 version of the ADC protocol was ready and the implementation had started to taking shape the protocol maintainers thought it’s a good idea to add information about the distinct new protocol of DC to Wikipedia. Besides linking to the technicals a brief description of what and why is ADC was added to the new Advanced Direct Connect Protocol page.

The page, professional and made according to the best Wikipedia standards, had been improved over time and stayed there for many years – until the end of last year when someone requested a complete removal, an uncontroversial deletion. This action was requested to be reverted (thanks to klondike) which means that per the Wikipedia rules the page itself cannot be requested to be removed again. However, a few weeks later, another admin made a lawnmover style deletion of the best part of the content of the page citing that the source of information, this very blog, where the most of the content are from the ADC protocol’s designers, maintainers and implementators, is unreliable.

Of course Wikipedia has its own rules and they have been controversial all the time. This time they’re clearly followed the rules unwisely and I guess it’s not worth to engage into an add/remove style fight with them anymore. Who knows, maybe cancel culture has reached Wikipedia as well or it’s just another attempt at making Wikipedia worse for technical purposes.

In any case we decided to preserve the removed document, originally added by Fredrik Ullner, here:

---

Advanced Direct Connect (ADC) is a peer-to-peer file sharing and chat protocol, using the same network topology, concepts and terminology as the Direct Connect (DC) protocol.

“ADC” unofficially an acronym for “Advanced Direct Connect”.^[1]

Contents

• 1 History
• 2 Design and features
• 3 Protocol
• 4 See also
• 5 References
• 6 External links

History

ADC was created to allow an extensible protocol and to address some shortcomings of the Direct Connect protocol. It was initiated by Jacek Sieka, under the influence of Jan Vidar Krey’s DCTNG draft.^[2] The first revision of ADC came in 2004 and the first official version in 2007-12-01.

Design and features

ADC is structured around clients that connect to a central hub, where the clients (users) can chat and download files from other clients (users). The hub provides routing between clients for chat, searches and requests for connections. The actual file transfers are between clients.

The protocol itself is split in two parts: a base protocol that every client and hub respectively must follow and extensions that are optional. The protocols allow signalling of protocol features (such as bloom filters), and messages can be constructed to only be routed to those who support that particular feature.

Each hub has their own rules and are commonly governed by hub operators.^[3] Hubs may define different capabilities for hub operators. The hubs themselves do not regulate discussion and files, but the hub operators. The hub regulate minimum share and maximum amount of simultaneous hubs; things that are sent by the client, rather than the user.

Lists of hubs ^[4] exist where a hub’s name, description, address and rules are specified. With the hub list, users can choose hubs that are similar according to the user’s liking of discussion topics and files.

The peer-to-peer part of the protocol is based on a concept of “slots” ^[5] (similar to number of open positions for a job). These slots denote the number of people that are allowed to download from a user at any time. The slots are controlled by the user of respective client.

ADC require that all text must be sent in UTF-8, which means that users with different system encoding (say, Russian and Chinese) are able to chat with respective native characters.

The protocol natively supports IPv6.

There are two modes a user can be in: “active” or “passive”. Clients in active mode can download from anyone else on the network. Passive mode users can only download from active users. Passive clients will be sent search results through the hub, while active clients will receive the results directly. An active searcher will receive (at most) 10 results per user and a passive searcher will receive (at most) 5 results per user. NAT traversal exist as a protocol extension,^[6] which allow passive users to connect to other passive users.

The base protocol does not require encryption, but extensions exist to provide encryption with TLS.^[7]

Files in client connections are identified by their hash, most commonly the Tiger Tree Hash. The hash algorithm is negotiated with the hub and used throughout the client-hub session, as well as subsequent client-client connections.

Protocol

The ADC protocol is a text-based protocol, where commands and their information are sent in clear text, except during password negotiation. The client-server (as well as client-client, where one acts as a “server”) aspect of the protocol stipulates that the client speak first when a connection has been made. For example, when a client connects to a hub’s socket, the client is the first to talk to the hub.

The protocol requires that all text must be sent as UTF-8 encoded Unicode, normalized in form C.

There are no port defaults, for hubs or clients.

Hub addresses are in the following form: adc://example.com:411, where 411 is the port.

During hub-client protocol information exchange, the client offers a set of hashes it supports. The hub will select one of these hashes, and that hash will be used throughout the hub-client session. If the hub deems that the client doesn’t support an (arbitrary) appropriate hash set, an error is raised.

The global identification scheme is based on the hash set producing two end-hashes, where one of them depends on the output of the other. During hub-client information exchange, the client will send these end-hashes, encoded with base32, which the hub will confirm to match. One of these base32 encoded hashes will be further sent to other clients in the network. The global identification scheme is this last string. The client may change its end-hashes on a hub-to-hub basis.

Each user, during a hub session, is assigned a hash that only lasts that particular session. This hash will be used for all client references in that hub. There is no dependency on nicks.

Each client information notification is incrementally sent.

An incoming request for a client-client connection is linked to an actual connection, with the use of a token.

Searches use a token, as well, to identify each result of a search.

There is no out-of-the-box ability for a client to kick or redirect another client from a hub. The hub, however, can kick and redirect arbitrarily. The hub can also require that all other clients in the hub must terminate their transfers with the kicked/redirected client. If a client is redirected to another hub, the redirecting client must use a referrer, similar to the HTTP referrer. The kicked/redirected client is not required to receive a notification message.

The peer-to-peer part of the protocol is based on a concept of “slots” (similar to number of open positions for a job). These slots denote the number of people that are allowed to download from a user at any time. These slots are controlled by the client. Automatic slot allocation is supported by the protocol.

The token in the client-client connection decides who should be allowed to download first.

Downloads are transported using TCP. Searches can be transported using TCP or UDP.

An active client has a listening port for TCP and another for UDP, though the ports don’t depend on each other.

Protocol delimiters are ‘\n’ and ‘ ‘ (space). The character ‘\’ is used as an escape sequence. Allowed escape sequences are “\n” (new line), “\s” (space) and “\\” (backslash).

The protocol allows for extensions such as compression with bzip2 or encryption with TLS.^[8] While the protocol does not mandate that these extensions be implemented, hubs may require them.

See also

• NeoModus Direct Connect protocol (NMDC)
• Comparison of ADC software

References

1. Fredrik Ullner (March 2007). “ADC: The run down”. DC++: Just These Guys, Ya Know? blog. Retrieved 2010-12-13.

2. Jan Vidar Krey (August 2006). “ADC: Protocol simplicity”.

3. Jan Vidar Krey. Archived from the original on 2013-01-30. Retrieved 2006-09-23.

4. Fredrik Ullner (March 2006). “Power + Person = Operator”. DC++: Just These Guys, Ya Know? blog. Retrieved 2010-12-13.

5. Fredrik Ullner (January 2007). “The parts of a hub list”. DC++: Just These Guys, Ya Know? blog. Retrieved 2010-12-13.

6. Fredrik Ullner (March 2006). “Slots, slots, slots…”. DC++: Just These Guys, Ya Know? blog. Retrieved 2010-12-13.

7. Fredrik Ullner (December 2010). “ADC Extensions – NATT – NAT traversal”. ADC Project. Retrieved 2010-12-13.

8. Fredrik Ullner (December 2010). “ADC Extensions – ADCS – Symmetrical Encryption in ADC”. ADC Project. Retrieved 2010-12-13.

9. En_Dator (March 2009). “TLS and Encryption”. ADCPortal. Archived from the original on 2011-07-07. Retrieved 2009-03-01.

External links

• The ADC Project
• ADC Protocol
• ADC Extensions
• DC Base – Discussion Forum for ADC Developers / Enthusiasts

---

Click here to see how the original Wikipedia page looked like before the content removal.

We’ve once had a very good overview of ADC at Wikipedia, a brief explanation of what it is all about so interested people can go further, contact, etc…. Now we have almost nothing. To compensate that I’ll also try to preserve this document another way by adding it to the ADC project site later.

May people with the powers to destruct valid and current information sleep better after each time they’re acting so.

DC++ 0.871 is out

A new testing version of DC++, 0.871 is pushed out today with only a few but very important updates of security and stability:

• Fixed a bug that restores web connections to certain servers with multiple hostnames, unfortunately including our SourceForge host server. This means that we’re unable to show the usual announcement of the available update at the start of previously released DC++ versions – therefore everyone should do the upgrade manually this time by visiting our official project host website’s download page. Please make sure, for your own safety, that you always download DC++ from the official site and not from other 3rd party websites search engines may suggest.
• Updated the secure connections library (OpenSSL) fixing a serious, rather easily exploitable issue that can allow malicious DOS attacks. This should certainly impact all released DC++ versions since 0.851, but older versions from the last 15 years might also be affected.
• Added a new, opt-out mechanism that time to time informs a random subset our userbase about possible new testing releases, similarly as it is done for stable releases, at the start of the program.

This important release should be marked as stable within a few days. Please everyone upgrade as soon as possible and due to the circumstances, this time, if you can, help us with encouraging others to do the same. Thank you!

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.