Encryption under NMDC

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.

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.

@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.

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.

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

DC++ not.

So we wanna know if it is intentionally or not.

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

@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

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.

Crise's very good assessment in post #8 still holds.

Inside the DC++ team we call this "NMDC feature freeze" something that is in effect since cca. 2008. It means that no new features and NMDC protocol compatibility should remain as it was in the point of time when the freeze imposed. The only exceptions are possible security issues.

However, the non-intrusiveness of H<>C TLS might make it possible to be considered for an addition as it may not break the above commitment:

- it doesn't change anything at the protocol level
- can be considered a security issue (see post #1)
- has constantly been requested by the hub owners due to security considerations
- is better for DC++ users (so they can connect all the hubs appearing in public hublists)

C<>C TLS is still a no go; applying the current client implementations would break both the line protocol, connectivity and compatibility freeze requirements.

NMDC H<>C TLS capability is added and has been released with DC++ 0.883.