Dithering or Traffic Encryption in Direct Connect, part 3
And no one pours young wine into old shabby bottles; otherwise the young wine will burst the bellows, and it will flow out, and the bellows will disappear; but new wine should pour new ones into the bottles; then both will be saved. Lk 5: 37.38
In April of this year, the administration of the world's largest DC hub announced the beginning of support for secure connections. Let's see what came of it.
Translate to English
')
Freedom of conscience
Since everything that I thought about this had already been expressed earlier , this part of the article should not have been at all.
Mafia
First, secure client-to-client connections are established regardless of the presence of client hub encryption.
Secondly, it is impossible to visually identify a hub that broadcasts or does not translate requests for secure connections.
Thirdly, today, almost all DC clients encrypt connections enabled by default.
Remember? Now let's check the TLS settings on the user side, connect to the hub and gently try to connect clients with each other.
NMDCs hub
DC ++ categorically refuses to secure connections on NMDC hubs, but it fully approves the usual ones. The reason for the developers voiced more than once - there is nothing to walk on the old rake!
StrongDC ++ can only TLS v.1.0, and modern clients do not connect to it at all. GreylinkDC ++ is still worse.
FlylinkDC ++ willingly falls into compatibility mode. How long is it and is it necessary at all? ..
EiskaltDC ++ does the same thing less willingly, just for its needs.
ADC hub (s)
Everything is exactly the same, but DC ++ is actively involved in the game. Encryption of traffic for it is possible only on ADC hubs.
EiskaltDC ++ does not seem to make a difference between NMDC and ADC hubs, strict with both. Good or bad - you decide.
So. And if you filter outdated clients, setting the input requirement of TLS v.1.2 support? ..
ADCs hub (s)
Comments, I believe, are superfluous.
findings
It may seem to the reader that it is best to use FlylinkDC ++ and have no problems, but one should not forget that this client is problematic in itself. One of the last incidents with which I was aware of was still not ticked off after updating the checkbox of supporting secure connections among many users and the actual absence of these in all its earlier versions.
Total, due to many historical and political reasons, the use of NMDC hubs as a base for secure inter-client connections is difficult or impossible. Using the NMDC hub, you are guaranteed to lose the ability to connect to a part of users, and in return, you get security - but without guarantees.
Recommendations
Start using ADC hubs, albeit in advance. Discard obsolete clients and, if you are the DC hub administrator, ban Strong and Gray. For
Every kingdom divided against itself will become empty; and any city or house divided against itself will not stand. Matt. 12:25
In April of this year, the administration of the world's largest DC hub announced the beginning of support for secure connections. Let's see what came of it.
Translate to English
')
Freedom of conscience
Since everything that I thought about this had already been expressed earlier , this part of the article should not have been at all.
If security is needed, choose a modern client and ADCs hub . Point.But what if you still use the NMDC hub, that is, the usual ? In this case, you will have to face the incompatibility of old, very old, new, or simply unconfigured DC clients. But - it was done, and the problems were not long in coming.
Mafia
First, secure client-to-client connections are established regardless of the presence of client hub encryption.
Secondly, it is impossible to visually identify a hub that broadcasts or does not translate requests for secure connections.
Thirdly, today, almost all DC clients encrypt connections enabled by default.
Remember? Now let's check the TLS settings on the user side, connect to the hub and gently try to connect clients with each other.
NMDCs hub
DC ++ categorically refuses to secure connections on NMDC hubs, but it fully approves the usual ones. The reason for the developers voiced more than once - there is nothing to walk on the old rake!
StrongDC ++ can only TLS v.1.0, and modern clients do not connect to it at all. GreylinkDC ++ is still worse.
FlylinkDC ++ willingly falls into compatibility mode. How long is it and is it necessary at all? ..
EiskaltDC ++ does the same thing less willingly, just for its needs.
ADC hub (s)
Everything is exactly the same, but DC ++ is actively involved in the game. Encryption of traffic for it is possible only on ADC hubs.
EiskaltDC ++ does not seem to make a difference between NMDC and ADC hubs, strict with both. Good or bad - you decide.
So. And if you filter outdated clients, setting the input requirement of TLS v.1.2 support? ..
ADCs hub (s)
Comments, I believe, are superfluous.
findings
It may seem to the reader that it is best to use FlylinkDC ++ and have no problems, but one should not forget that this client is problematic in itself. One of the last incidents with which I was aware of was still not ticked off after updating the checkbox of supporting secure connections among many users and the actual absence of these in all its earlier versions.
Total, due to many historical and political reasons, the use of NMDC hubs as a base for secure inter-client connections is difficult or impossible. Using the NMDC hub, you are guaranteed to lose the ability to connect to a part of users, and in return, you get security - but without guarantees.
Recommendations
Start using ADC hubs, albeit in advance. Discard obsolete clients and, if you are the DC hub administrator, ban Strong and Gray. For
Every kingdom divided against itself will become empty; and any city or house divided against itself will not stand. Matt. 12:25
Source: https://habr.com/ru/post/449728/
All Articles