Encryption of traffic in Direct Connect, part 1
But he said to them: kings rule over the nations, and the owners of them are called benefactors, but you are not like that: but who among you is more, be like the least, and the ruler as a servant.
I started to sin with the Internet since 2004, and at first the local LAN was tempted. More precisely, the program called DC ++ 0.401, which magically gave access to files shared by other subscribers of the same LAN. To do this, it was necessary to connect to one or several nodes of the file-sharing network, called hubs. The hubs themselves were kept on their computers by local enthusiasts.
It soon became clear that the same can, in principle, be done not only within the local network, but also through the Internet ... Communicate, make friends, swear, negotiate, create your own resources, promote them, improve, try other customers, look for holes and vulnerabilities , engage in industrial espionage, communicate with developers, etc. etc.
Warm lamp DC ++ v. 0.401
In general, DC with its simple functions of communication and file sharing successfully served as a social network of those times. And the human face on the other side of the screen looked as much as you yourself wanted to see it.
Years have passed. Local hubs were blown away and died. Under the onslaught of Facebook, VKontakte and DC torrent, it shrank to less than five hundred public hubs on the old NMDC protocol and a dozen (sic!) On the A dvanced D irect C onnect protocol.
As dear readers already know, all Russian traffic is saved for the time being. Giving it in the clear is unhygienic, but this is exactly what Direct Connect users do.
So what is required? First, encrypt the client DC communication with the hub. Secondly, encrypt communication between customers.
And this is where the problems begin at all levels of this simple digital hierarchy, so similar to the human society.
Suddenly, suitable hubs are not detected. On the old NMDC protocol, they are not physically present. ADCs have had hubs since about 2008, but they do not make the weather, for they have remained so little. Therefore, such a resource will have to be deployed independently from the already existing ADC hub.
Software support for TLS in DC clients has been around for a long time , but since there were no cases for its use, no one looked in this section of the settings either. And in vain!
Converting an existing ADC hub to encryption is easy. Generate a self-signed certificate, feed it to the engine, select the TLS "policy".
But the fact is that an encrypted connection with the hub is established when using a link like adc s : //hub.address.com: port
Configuring the TLS “policy” is to either approve regular connections (that is, follow a link like adc: //hub.address.com: port), or redirect such a user somewhere (for example, to the “correct” address ).
The first means that users with clients who are not able to TLS versions above 1.0 (or are not able at all) will be able to connect to the hub, which will create problems; and the second is that attendance will fall by at least a third.
Yes, it turns out, the hub in this case acts as a kind of censor and guarantor of the nominal possibility of secure inter-client connections.
It is necessary to understand that this statistics was obtained byblood and water experimentally for the ADC hub, which old customers cannot work with. NMDC hub after such a transition will simply cease to exist as a resource, because you actually need to change the address, and require users to replace customers with more modern ones. By the way, why didn't they do this before? ..
The old protocol has one global flaw: the inability for the network to work as one with the number of hubs is more than one . Yes, for local networks one big hub is the norm, but de facto one user at two different hubs are two completely different users from all possible points of view (except the user himself, but this is not certain).And if you manage to connect to the hub more than once, then the full stuffing begins.
Administrators and owners of large DC hubs at the moment are interested only in the number of users online and what can be had from it. Users are bought and sold; there is no culture of interaction between administrators and users, there is no community. If there is no morality, if you like, along with ethics and the concept of norms, and problems that arise arise are solved by concepts. Do you remember the literal translation of the word server? ..
So it turns feudal fragmentation. It is more profitable (for whom?) To allow everything to everyone (for example, to use clients that are outdated 10 or more years ago with known vulnerabilities ) than to act as a guarantor of anything.
What the owners of the hubs did for sure was that they pissed off users with spam demanding to go somewhere or for some reason to register instead of distributing clear instructions in the event of typical situations.
I didn’t add the popularity of DC at the time and the need for port forwarding on the router and the knowledge of the "quality" of my IP address. The procedure is not difficult, but still causes problems.
As a result, at the moment to convey to the user of the hub within the hub itself, useful information is problematic. Do not read!
We reviewed the theory and problems of transferring a cozy file exchange in the framework of Direct Connect to the use of modern encryption required in our day. As you can see, for this we had to point out the flaws in the interaction between the user <=> client program <=> hub <=> administratorand invent it again .
In the second part of the article it is planned to consider the practice of selecting and configuring a DC client to work on the ADCs hub.
Story
I started to sin with the Internet since 2004, and at first the local LAN was tempted. More precisely, the program called DC ++ 0.401, which magically gave access to files shared by other subscribers of the same LAN. To do this, it was necessary to connect to one or several nodes of the file-sharing network, called hubs. The hubs themselves were kept on their computers by local enthusiasts.
“ DC ++ ” is the name of the client. The protocol is called “ D irect C onnect”. DC hubs. DC clients.It had its own charm. Here you are outside the network, but already inside, among people who have done approximately the same actions as you previously did. Amazing, right?
It soon became clear that the same can, in principle, be done not only within the local network, but also through the Internet ... Communicate, make friends, swear, negotiate, create your own resources, promote them, improve, try other customers, look for holes and vulnerabilities , engage in industrial espionage, communicate with developers, etc. etc.
Warm lamp DC ++ v. 0.401
In general, DC with its simple functions of communication and file sharing successfully served as a social network of those times. And the human face on the other side of the screen looked as much as you yourself wanted to see it.
Years have passed. Local hubs were blown away and died. Under the onslaught of Facebook, VKontakte and DC torrent, it shrank to less than five hundred public hubs on the old NMDC protocol and a dozen (sic!) On the A dvanced D irect C onnect protocol.
Start
As dear readers already know, all Russian traffic is saved for the time being. Giving it in the clear is unhygienic, but this is exactly what Direct Connect users do.
So what is required? First, encrypt the client DC communication with the hub. Secondly, encrypt communication between customers.
And this is where the problems begin at all levels of this simple digital hierarchy, so similar to the human society.
Hubs
Suddenly, suitable hubs are not detected. On the old NMDC protocol, they are not physically present. ADCs have had hubs since about 2008, but they do not make the weather, for they have remained so little. Therefore, such a resource will have to be deployed independently from the already existing ADC hub.
Customers
Software support for TLS in DC clients has been around for a long time , but since there were no cases for its use, no one looked in this section of the settings either. And in vain!
Converting an existing ADC hub to encryption is easy. Generate a self-signed certificate, feed it to the engine, select the TLS "policy".
But the fact is that an encrypted connection with the hub is established when using a link like adc s : //hub.address.com: port
Configuring the TLS “policy” is to either approve regular connections (that is, follow a link like adc: //hub.address.com: port), or redirect such a user somewhere (for example, to the “correct” address ).
#tls_version = 1.0 tls_private_key="/etc/uhub/babylon.aab21pro.org.key" tls_certificate="/etc/uhub/babylon.aab21pro.org.crt" tls_enable=yes tls_require=yes tls_require_redirect_addr=adcs://babylon.aab21pro.org:412 The first means that users with clients who are not able to TLS versions above 1.0 (or are not able at all) will be able to connect to the hub, which will create problems; and the second is that attendance will fall by at least a third.
*** SSL Error 1: tlsv1 alert protocol versionSuch a message when trying to connect to the ADCs hub displays a client who can only TLS v.1.0
Yes, it turns out, the hub in this case acts as a kind of censor and guarantor of the nominal possibility of secure inter-client connections.
It is necessary to understand that this statistics was obtained by
Admins
The old protocol has one global flaw: the inability for the network to work as one with the number of hubs is more than one . Yes, for local networks one big hub is the norm, but de facto one user at two different hubs are two completely different users from all possible points of view (except the user himself, but this is not certain).
Administrators and owners of large DC hubs at the moment are interested only in the number of users online and what can be had from it. Users are bought and sold; there is no culture of interaction between administrators and users, there is no community. If there is no morality, if you like, along with ethics and the concept of norms, and problems that arise arise are solved by concepts. Do you remember the literal translation of the word server? ..
So it turns feudal fragmentation. It is more profitable (for whom?) To allow everything to everyone (for example, to use clients that are outdated 10 or more years ago with known vulnerabilities ) than to act as a guarantor of anything.
Users
What the owners of the hubs did for sure was that they pissed off users with spam demanding to go somewhere or for some reason to register instead of distributing clear instructions in the event of typical situations.
I didn’t add the popularity of DC at the time and the need for port forwarding on the router and the knowledge of the "quality" of my IP address. The procedure is not difficult, but still causes problems.
As a result, at the moment to convey to the user of the hub within the hub itself, useful information is problematic. Do not read!
Results
We reviewed the theory and problems of transferring a cozy file exchange in the framework of Direct Connect to the use of modern encryption required in our day. As you can see, for this we had to point out the flaws in the interaction between the user <=> client program <=> hub <=> administrator
In the second part of the article it is planned to consider the practice of selecting and configuring a DC client to work on the ADCs hub.
Source: https://habr.com/ru/post/438264/