Encryption of traffic in Direct Connect, Part 2

- Who are you???
- I am a new Russian.
- And then who am I?

Foreword

In the first part of the article, we built the ADCs hub and talked about Direct Connect as a whole.

Today we have to learn how to use such a hub for its intended purpose. To do this, we’ll talk about the features of compatible DC clients and make them friends with TLS.

In the settings of each of them, you will need to pay attention to the Encryption section, also known as Security & certificates or Security .

Needless to say, when using the active mode, the TCP port for TLS should also be forwarded.

AirDC ++

The advanced heir of the legendary fulDC ++, the very first fashion of the original client. Visible and adequate.


AirDC ++ settings for working on ADCs hub

The key and certificate are generated when the client is first started (or on demand) and valid for 360 days.



Note that when connecting clients to each other, TLS can also be used on a normal ADC hub, but with an unpredictable result (see the previous part of the article).

And what for the client is hub with trusted certificate ?

As the tests showed, even if you feed the real hub, a certificate signed by the authorization center (or at least from Let's Encrypt), it will not be trusted for the client.


[S] = Secure, [U] = Untrusted

The criterion of trust for the ADCs of the hub is the coincidence of the certificate fingerprint obtained by the client itself with the explicitly indicated in the address of the hub.

*** Connecting to adcs: //babylon.aab21pro.org: 412 /? Kp = SHA256 / 1QTHF6U3SDQPQKCCGGZZYK4LQS322MIXI64GMAX7PXLGKYCYTJOQ ...
*** TLS error: Keyprint mismatch
*** The keyprint does not match the server certificate.

It is touching, but useless, because the keyprint will not be forever the same; which means it is not suitable for mass use.

A better way to get the coveted [S] is to save the hub certificate in a folder specifically designed for this (it usually coincides with the one in which the client stores its own "documents"). The certificate, of course, must be requested from the hub administrator.

What is direct encrypted private message channels ?

DC ++, AirDC ++ and, suddenly, SharikDC can send private messages to each other over a secure channel , bypassing the hub. Hello, Telegram! ..

DC ++

The original NMDC / ADC client, the most unassuming. However, the safety of its developers pay a lot of attention.


DC ++ settings for working on ADCs hub

ApexDC ++


ApexDC ++ settings for working on ADCs hub

The most tolerant. It focuses on the security settings of the remote client - therefore, along with the secure ones, normal connections can also be skipped (for example, with unconfigured FlylinkDC ++).

Anyway, this is the best option for hot-swappable, outdated StrongDC ++.

EiskaltDC ++


EiskaltDC ++ settings for working on ADCs hub

FlylinkDC ++

The most strict and most inadequate. And the translation of options is not quite correct.


Settings FlylinkDC ++ to work on ADCs hub

Strict, because it requires all and all signed certificates , which still can not verify . Inadequate, because by default it completely ignores secure connections and allows normal ones.


AirDC ++ vs. FlylinkDC ++

Epilogue

If the connection is successfully established using TLS (for example, when downloading a filelist), the Cipher or Cipher column in the transmission window will be filled (in AirDC ++, otherwise, see below)



As you can see, not without rough edges, but TLS in DC takes place and works; There are plans to further develop this topic. By the way! On February 10th of this year, the first online meeting of the DC community this year will be held at 19:00 CET at the DCNF office . there will be a public discussion of one new idea ... Interesting? Then go for a light!