Encryption under NMDC

[Toast]

Well it seems like a popular demand so lets drag this topic thru the mud once again

as we all know it is possible to encrypt c-c transfers but now there is also the option to encrypt c-h traffic aswell and since nmdc is predominant on direct connect it would benefit dc++ too actually encrypt this traffic since mods already have this support again strongdc++ along with all its subclients

request taken from: http://www.adcportal.com/forums/viewtopic.php?f=13&t=769

[Kcchouette (kcchouette)]

Hello

Now we are in 2019
This issue, that have been tagged as "Importance: wishlist" in 2013, should have been tagged as "Importance: very important" now.

Encryption is really important in a world where all want information about you for nothing.

[Crise / MW (markuwil)]

There is already a released fix for this issue... it is called ADC(S).

NMDC already has way too many ADC features backported to it already, at some point people will just have to choose to move on [to ADC, hopefully] or simply live with its current deficits.

[Kcchouette (kcchouette)]

@Crise: Sadly it's not a release fix.
Like you may know, NMDC is still supported by DCNF.

Maybe by stopping this support, it'll give a big signal to others?

Or if we continue to support it, then this is still an issue.

[Crise / MW (markuwil)]

DCNF does indeed support NMDC, if that is the word you would like to use. However, the primary role for DCNF in regards to NMDC at the moment is just that of retaining information for all intents and purposes.

As far as I am aware there are no plans to actively develop NMDC further, in any capacity, at least no-one has indicated such when it comes to DCNF. As far as client developers are concerned everyone has to make their own call on this issue as DCNF has no direct power over client developers. As far as I know DCNF also has no official opinion on encryption in NMDC as such.

However, what I can say is that an implementation for TLS in NMDC does indeed exist, whether DC++ or any other client chooses to implement that or some other variant of TLS for NMDC is up to every project individually.

What DCNF can do is document the protocol extensions for NMDC, and I use that term loosely, and honestly from the top of my head I am unsure if this is currently the case or not.

[Delion (delion)]

Crise, ApexDC++ seems to work just fine with NMDCs.

DC++ not.

So we wanna know if it is intentionally or not.

[Delion (delion)]

P.S. I'm not a big fun of NMDCs too, just curious.

[Kcchouette (kcchouette)]

@Delion: One problem that point @Crise by his comment is that even if "ApexDC++ seems to work just fine [...] DC++not", like NMDCs is not written in specification -> "whether DC++ or any other client chooses to implement that or some other variant of TLS for NMDC is up to every project individually."

Here in you screenshot you (Delion) seem to underligne that C-C in NMDCs hub using TLS fails, isn't it?

But the specification only state "URI scheme is dchub:// for unencrypted and nmdcs:// for encrypted connections."[1], so here the term "encrypted connections" can just be the login between Client-Server...

And so by extension (and adding that I understand from Crise) "the implementation of TLS inside NMDC for this or that component is up to the developer of the DC client"

[1]: https://github.com/direct-connect/protocols/blob/master/nmdc/nmdc.md#general

[Crise / MW (markuwil)]

To clarify, H<>C TLS is fairly non-intrusive from protocol point of view as far as simply supporting the nmdcs URI is all it is in terms of how it exists currently if memory serves.

The C<>C TLS as it is implemented by DC++ derivatives and some other clients, on the other hand, is reliant on some pretty specific quirks in parsing of certain protocol commands. These existing quirks allowed clients such as StrongDC (being among one of the first to support this, if memory serves) to effectively brute force TLS signaling into the NMDC protocol in a way that is non destructive with most current implementations of the protocol.

The problem with C<>C TLS being achieved in this way is that it is extremely brittle and it will continue to be so because NMDC commands are not designed to be extended in this or any other way. This particular implementation just happened to find a hole in command parsing and made effective use of it (I honestly don't recall the specifics off the top of my head as to whether this quirk is such that it could be re-used, or has it now been in effect "used up" by this hack).

Either way, this issue perfectly demonstrates why trying to patch NMDC is an exercise doomed to fail, not only because most people can't agree on how things should be done and there is also the issue of a segment of NMDC users that essentially operate on legacy software. To put it a different way, any change to NMDC has to be a bespoke one, there is no affordance for developing the protocol built into NMDC which means you would have to have clients and servers in a consensus on set of features and behaviors which will never happen. This is why ADC's command structure is so liberating.

Although, I would like to add a reminder that this is a DC++ bug tracker, and while I am unsure what the current stance of DC++ is in regards to changing the NMDC implementation if I recall correctly there is, or at least used to be, a sort of an unwritten rule not to introduce changes to NMDC (in DC++), for reasons already stated. The only exception for this in relatively recent memory is the addition of Referrer information to established connections in so far as I can recall.

In short, you could always gamble by providing a patch and bringing it up with the DC++ developers, because it is fairly unlikely anything will happen otherwise because it is not guaranteed that anything would happen even then, the issue of the NMDC "specification" is somewhat off-topic for this bug tracker.