DC++ 0.850

The first new DC++ release in the last nine months, version 0.850 fixes and hardens security related functions further notably to avoid all popular TLS exploits emerged since last April.

This release also contains stability and performance updates of various 3rd party libraries and improvements of the latest version of the compiler.

For complete list of fixes and upgraded libraries, please explore the changelog items and the linked bug discussions.

DC Development hub revived

Following a two-month-long hiatus, adcs://hub.dcbase.org:16591 hosts the DC development hub again.

DC++ 0.842

The first stable release of the 0.840 series of DC++ is out. Besides a few SSL encryption related and stability fixes this version largely focuses on implementing various features asked for or recommended by the user community through our feature tracker.

The changelog shows all the implemented new features and fixes.

DC++ 0.842 also provides protection against the infamous “Heartbleed” OpenSSL vulnerability. This security hole has existed in DC++ since version 0.799.

There’s a high chance of version 0.842 is the last mainstream DC++ release that supports Windows XP.  Due to the still large userbase of the already unsupported operating system, security and major stability fixes are possible for a few more months using a separate branch targeting XP only. The update reminder system is modified so in case of any forthcoming version targeting Vista and later being released, XP users won’t see the notification dialog anymore.

From that time on people running Windows XP will see the update nag dialog only if there’s an update targeting their old OS. However, starting with version 0.840 every XP user gets a special reminder at startup about the EOS of DC++ in their operating system.

Due to the nice new features and security fixes the upgrade is highly recommended.

DC++ 0.831

A new bug fixing service release of DC++ has been released today fixing the following problems introduced with version 0.830:

  • One of the bugs, marked as critical, prevents DC++ to respond to TTH searches on NMDC hubs.
  • A problem with too small protocol command size limits can cause problems for hubs sending large user commands.
  • The newly introduced direct encrypted private message channels are getting disconnected after some idle time.

All the fixed problems exist in version 0.830 only thus older versions are not affected. For users running DC++ 0.830 the upgrade is highly recommended.

DC++ 0.830

Today we marked the first version of  the 0.83x series of DC++ as stable. The new release brings plenty of stability updates as well as introduces a new ADC feature to improve privacy.

The privacy improvement is actually an implementation of an ADC protocol extension called CCPM. Basically, it allows two peers to initate an SSL encrypted direct connection channel for sending and receiving private messages.

Until now, all private messages in the DC network has been gone through a hub where both users were logged in. While this method is great for controlling unwanted messages (spamming) it also makes possible for the hub owner to spy on any private communications.

Enter CCPM, a feature that still needs a hub to initiate the direct encrypted connection but the hub is needed only for the start. After the direct channel has been estabilished the messages go directly between the peers in an encrypted way. The channel initiation requires the two users to be logged on a secure ADC hub (ADCS).

The whole discussion of the protocol features and CCPM implementation can be found here (the implementation details with screenshots starts in this position of the thread). The built-in help of DC++ also describes the feature in the Private message window page and the availabe controlling options in the Certificates’ settings page (once updated, links will be added to  the web version of the DC++ help, too).

The list of other fixes in version 0.830 speak for themselves yet again this time, explore the changelog items and the linked bug discussions in them for more information.

BEAST, CRIME, BREACH, and Lucky 13: Assessing TLS in ADCS

1. Summary

Several TLS attacks since 2011 impel a reassessment of the security of ADC’s usage of TLS to form ADCS. While the specific attacks tend not to be trivially replicated in a DC client as opposed to a web browser, remaining conservative with respect to security remains useful, the issues they exploit could cause problems regardless, and ADCS’s best response thus becomes to deprecate SSL 3.0 and TLS 1.0. Ideally, one should use TLS 1.2 with AES-GCM. Failing that, ensuring that TLS 1.1 runs and chooses AES-based ciphersuite works adequately.

2. HTTP-over-TLS Attacks

BEAST renders practical Rogaway’s 2002 attack on the security of CBC ciphersuites in SSL/TLS by using an SSL/TLS server’s CBC padding MAC acceptance/rejection as a timing oracle. Asking whether each possible byte in each position results in successful MAC, it decodes an entire message. One can avert BEAST either by avoiding CBC in lieu of RC4 or updating to TLS 1.1 or 1.2, which mitigate the timing oracle and generate new random IVs to undermine BEAST’s sequential attack.

CRIME and BREACH build on a 2002 compression and information leakage of plaintext-based attack. CRIME “requires on average 6 requests to decrypt 1 cookie byte” and, like BEAST, recognizes DEFLATE’s smaller output when it has found a pre-existing copy of the correct plaintext in its dictionary. Unlike BEAST, CRIME and BREACH depend not on TLS version or CBC versus RC4 ciphersuites but merely compression. Disabling HTTP and TLS compression therefore avoids CRIME and BREACH.

One backwards-compatible solution thus far involves avoiding compression due to CRIME/BREACH and avoiding BEAST with RC4-based TLS ciphersuites. However, a new attack against RC4 in TLS by AlFardan, Bernstein, et al exploits double-byte ciphertext biases to reconstruct messages using approximately 229 ciphertexts; as few as 225 achieve a 60+% recovery rate. RC4-based ciphersuites decreasingly inspire confidence as a backwards-compatible yet secure approach to TLS, enough that the IETF circulates an RFC draft prohibiting RC4 ciphersuites.

Thus far treating DC as sufficiently HTTP-like to borrow their threat model, options narrow to TLS 1.1 or TLS 1.2 with an AES-derived ciphersuite. One needs still beware: Lucky 13 weakens even TLS 1.1 and TLS 1.2 AES-CBC ciphers, leaving between it and the RC4 attack no unscathed TLS 1.1 configuration. Instead, AlFardan and Paterson recommend to “switch to using AEAD ciphersuites, such as AES-GCM” and/or “modify TLS’s CBC-mode decryption procedure so as to remove the timing side channel”. They observe that each major TLS library has addressed the latter point, so that AES-CBC might remain somewhat secure; certainly superior to RC4.

3. ADC-over-TLS-specific Concerns

ADCS clients’ and hubs’ vulnerability profiles and relevant threat models regarding each of BEAST, CRIME, BREACH, Lucky 13, and the RC4 break differ from that of a web browser using HTTP. BEAST and AlFardan, Bernstein, et al’s RC4 attack both point to adopting TLS 1.1, a ubiquitously supportable requirement worth satisfying regardless. OpenSSL, NSS, GnuTLS, PolarSSL, CyaSSL, MatrixSSL, BouncyCastle, and Oracle’s standard Java crypto library have all already “addressedLucky 13.

ADCS doesn’t use TLS compression, so that aspect of CRIME/BREACH does not apply. The ZLIB extension does operate analogously to HTTP compression. Indeed, the BREACH authors remark that:

there is nothing particularly special about HTTP and TLS in this side-channel. Any time an attacker has the ability to inject their own payload into plaintext that is compressed, the potential for a CRIME-like attack is there. There are many widely used protocols that use the composition of encryption with compression; it is likely that other instances of this vulnerability exist.

ADCS provides an attacker this capability via logging onto a hub and sending CTMs and B, D, and E-type messages. Weaponizing it, however, operates better when these injected payloads can discover cookie-like repeated secrets, which ADC lacks. GPA and PAS operate via a challenge-reponse system. CTM cookies find use at most once. Private IDs would presumably have left a client-hub connection’s compression dictionary by the time an attack might otherwise succeed and don’t appear in client-client connections. While a detailed analysis of the extent of practical feasibility remains wanting, I’m skeptical CRIME and BREACH much threaten ADCS.

4. Mitigation and Prevention in ADCS

Regardless, some of these attacks could be avoided entirely with specification updates incurring no ongoing cost and hindering implenetation on no common platforms. Three distinct categories emerge: BEAST and Lucky 13 attacks CBC in TLS; the RC4 break, well, attacks RC4; and CRIME and BREACH attack compression. Since one shouldn’t use RC4 regardless, that leaves AES-CBC attacks and compression attacks.

Disabling compression might incur substantial bandwidth cost for little thus-far demonstrated security benefit, so although ZLIB implementors should remain aware of CRIME and BREACH, continued usage seems unproblematic.

Separately, BEAST and Lucky 13 point to requiring TLS 1.1 and, following draft IETF recomendations for secure use of TLS and DTLS, preferring TLS 1.2 with the TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 or other AES-GCM ciphersuite if supported by both endpoints. cryptlib, CyaSSL, GnuTLS, MatrixSSL, NSS, OpenSSL, PolarSSL, SChannel, and JSSE support both TLS 1.1 and TLS 1.2 and all but Java’s supports AES-GCM.

Suggested responses:

  • Consider how to communicate to ZLIB implementors the hazards and threat model, however minor, presented by CRIME and BREACH.
  • Formally deprecate SSL 3.0 and TLS 1.0 in the ADCS extension specification.
  • Discover which TLS versions and features clients (DC++ and variations, ncdc, Jucy, etc) and hubs (ADCH++, uHub, etc) support. If they use standard libraries, they probably all (except Jucy) already support TLS 1.2 with AES-GCM depending on how they configure their TLS libraries. Depending on results, one might already safely simply disable SSL 3.0 and TLS 1.0 in each such client and hub and prioritize TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 or a similar ciphersuite so that it finds use when mutually available. If this proves possible, the the ADCS extension specification should be updated to reflect this.

Team organization structure proposal

Direct Connect is very loosly organized and has always been. There are a few people that control resources, be it websites, software or hubs. However, the idea of a strict hiearchy is by many appalling and that is why there is no designated ‘boss’ person. Indeed, simply appointing someone is directly not possible because of the structure of developers and projects. There is no one that decides what to do or what must be done. Everyone is a volunteer and pitch in when they can and want to. It is why I think that we should not focus on a person that ‘delegates’ tasks to people, rather we should focus on what we want to accomplish and what we want to do in the community.

That is why I propose a new type of organization breakdown, focusing on work area and interest area, ‘teams’ or ‘workgroups’. The intent with the teams is to provide a clear message to others what we’re working on and how they can help for that group. For example, a person that is interested in security can provide information in the ‘security team’ whilst not feeling a requirement to participate with the interoperability of software. The point of the team is not to say “these people have to produce content for this team”, but rather “these people know some stuff that pertain to this subject” and serves as an encouragement for them to provide content (documentation or software etc). The purpose with all teams must be to better the DC community in some way. My hope is that participation in a team is meant to spur people into working on that team’s issues and future (i.e. a commitment to oneself). Of course, anyone can submit information and help a team. A clear intent on what the community or team needs can allow new people to help with the community.

My proposal is also to have a team leader that tries to encourage other participants in the team to provide data. Do note that I do not mean “hey, do that” but rather “hey, I think you have knowledge about a subject, could you check out if it’s something you’d be interested in and write anything on the subject”.

By the way, teams aren’t meant to be static: they can change and new ones can be introduced and old ones can be removed.

In addition to the team leader, I propose that teams have a cyclic report on what been done in the past X. For example, if there has been lots of stuff going on with security (be it documentation or even discussion) in the past week, it should be lifted in the blog and forum, so we can have summaries of decisions or interesting avenues.

Teams I have thought of:

  • Security – Overarching adressing security
  • Cryptography – A subteam for security that focuses on math and cryptography itself
  • Software – Overarching addressing software in terms of clients, hubs and others items
  • Interoperability – A subteam to software that addresses interoperability issues that arise between software
  • Protocol – Addresses the needs of the protocols both in terms of software support but also in terms of documentation and standardization
  • Infrastructure – Addresses needs in the infrastructure of projects

I have only created an intial description of security and cryptography (below) but I will add more later on. Also, I’ve created forums for each of those items at dcbase.org

Team: Security

Purpose: Investigate and publish items relating to security.

The team will gather and inform the community on any security related issue that arises directly within DC or if external data that may be of interest for the DC community.

The following are items addressed:

  • Auditing of attack vectors:
  • Protocol messages
    • Content passed over implementation boundaries
      • File list
      • Hublist
      • Other messages that others must react to (e.g., chat messages relating to magnet URI parsing)
    • External sources of information (URIs)
    • Certificate management
  • Auditing of protocols:
    • Message structure and content
    • Providing information for protocol parsers (wireshark, profilers, sniffers, packet-shapers)
  • Auditing of implementations:
    • Spam/Flood protection mechanisms (and other DoS-related content)
    • XML parsers (file list, hublist, zip-bombs)
    • Protocol message parsers
    • Hammering of hub after kick (reconnect timer etc)
    • External library implementations (SSL, BZIP, XML etc)
    • Source references (RF field etc)
  • Other points for audit:
    • Hublist retrieval (distributed etc)
    • version.xml retrieval (distributed etc)
    • Audit of DC architecture
    • Nature of data broadcasts
    • Hub controls content
    • Hub is fully trusted
    • Distribution of hub/dns etc
  • Post and review of CVEs
  • Security companies contact
  • Audit and review external security related reports that relate to DC

Team: Cryptography

Purpose: Investigate and publish items relating to cryptography.

The team will gather and inform the community on any cryptographic issue that arises directly within DC or if external data that may be of interest for the DC community.

The team will provide a description of the cryptographic solutions currently employed. The team will also provide information about cryptographically related content such as hashing, as the latter may benefit from analysis of the former.

Functionality that will be included as protocol extensions will be discussed with the appropriate protocol team.

The team will inform the community as clearly as possible, providing necessary information for cryptologists as well as for the lay person. A report of the current discussions and results will be published on a regular basis (monthly if there have been any new content).

The crypto-team is related to the security team. However, the former’s job is to focus any cryptography while the latter is focused on general security related content. As such, the security team will only address cryptography based on the crypto-team’s reports.

Software that influence or validates the cryptography functionality will also be provided.

The following are items addressed:

  • Certificate management for client – client and client – hub connections
  • Hash management
    • Tiger Hash
    • Potential successors to Tiger (Tree) Hash: SHA-2, SHA-3
    • Protocol support with ADC and NMDC
    • Implementation support
    • Sharing hash databases


Get every new post delivered to your Inbox.

Join 30 other followers