It would not be hard at all. China, Iran and Russia already do that. Clienthello is not encrypted and that is all you need.
And ECH would not solve this as you can just block cloudflare-ech (or other, depending on CDN) domain itself and force clients to fallback to non-encrypted clienthello.
Everyone gansta till DPI system is installed.
That’s just VPN with extra steps. Why not just set up a SOCKS5/Shadowsocks/wireguard/whatever on any hosting and get a lot better experience?
Telegram published a statement on X/Twitter that they are not changing any policy. The just removed misleading line in their FAQ, that stated that you can’t report private chats (which you always could).
If xmpp and matrix are included, why not include email?
Guy, I visit yandex.ru every day. It is my homepage.
It seems to me that you did not read my message, so here is the repeat:
Here is even some proof of that: https://www.reuters.com/markets/europe/russia-tightens-grip-media-yandex-sells-homepage-news-rival-vk-2022-08-23/
As I said earlier, it is only somewhat similar to TLS-in-TLS blocking. I do not have exact articles right now, and it is not easy to google them, since almost all of them are in Chinese.
But here is for example, a proof of concept of a tool, that detects TLS-in-TLS: https://github.com/XTLS/Trojan-killer
It is incomplete and I do not know if it uses the same methods as Chinese censors, but it still proves the possibility.
If you still require more concrete proff, then, I will try to find an article in my free time and if I do, I would reply to your comment again after that (it is not going to be in the nearest future.
Please explain how are you imagining that
I do not have right now links to articles about that exactly, but here is an old article about somewhat similar tactics that China uses to block encrypted proxy protocols like shadowsocks, for example: https://gfw.report/publications/usenixsecurity23/en/
I’m talking about encapsulating traffic in an encrypted tunnel.
As I I have previously mentioned, if you are encapsulating all traffic in an encrypted tunnel, then most of the data would have two layers of encryption. This can be detected, and, in fact is being detected in China and, experimentally, in Russia.
The beautiful website I’ve imagined for a situation where some DPI robot will, say, visit it to check that there really is a website there.
That is a good protection against active probing, but active proving is not the only detection method, available for censors.
You also seem to be mixing up such entities as VPNs, proxies and encapsulation.
How did you come to this conclusion?
BTW, I’m using VPNs in Russia from time to time. Something doesn’t work, something does.
What are you trying to say here? What does work? What does not?
I’m describing a specific kind of encapsulation.
What I understood from you is that you are talking about encapsulating TLS-encripted traffic in https, TLS-encripting it again. If I understood you wrong, please correct me. There are countless software solutions for that, but they are not panacea, because double layer of encryption can be detected and your beautiful website does not need encryption-on-top-of-encryption. It is obvious that you are reaching something else.
It is going to show the censor that you are trying to reach different banned websites (and, probably, google, facebook, etc), all hosted on your server. Your beautiful website is all fine, but in clienthello there is still google.
It is not necessary fingerprinting of clients, you can fingerprint the server as well. GnuTLS for this particular purpose is used only by Openconnect and that is just an example. This tactic is very effective in China and Russia and collateral damage is insignificant.
And various western anti-censorship organizations wrote articles, that such methods are not possible in Russia as well, but here we are. China’s yesterday is Russia’s today, American tomorrow and European next week. Here it all started in the exact same manner, by requiring ISPs to block pirate websites. And between this and blocking whatever you want for the sake of National Security (for example, against Russian hackers) is not such a long road as you think it is.
At first, please, be a little bit more patient and no, I am not a LLM.
All https traffic is https-encapsulated by definition. And you can look inside https just fine. The problem is that most of data is TLS-encripted. However, there is so-called “clienthello” that is not encripted and can be used to identity the resource you are trying to reach.
And if you are going to https-encapsulate it again (like some VPN and proxy protocols do) data will have TLS-encription on top of TLS-encription, which can be identified as well.
And about libraries: VPN protocol Openconnect, for example uses library gnutls (which almost no one else uses) instead of more common openssl. So in China it is blocked using dpi by this “marker”.
By the same logic they should not be able to force ISPs to ban sites, but here we are. If they can enforce bans with ISPs, why can’t they do the same with VPN providers?
Https does not actually make difference here. You can still detect VPN usage by unencrypted clienthello, encryption-inside-encryption, active probing, obscure libraries that vpn protocol depends on, etc.
VPNs are not categorically banned in Russia either. Just 95% of them. Categorical ban is not actually required here. Government can just create licensing procedure and license only those VPNs, which follow “rules”. I do not see how this is different from ISP bans.
As a guy from Russia, I must admit that vpns are not a big problem for censors. They can be easily blocked, including self-hosted ones by protocol detection. And DNS would not do much with IP and clienthello-based blocks. And most users are not enough tech-savvy to constantly switch to new protocols as old ones get blocked.
From what I understand, their own domains are not actually decentralized. Each of them has it’s own “authority” that can control what is or is not allowed to be registered. Emercoin domains look more promising, but I am not knowledgeable enough about them to say that they are actually decentralized. I would say that the closest thing to fediverse is DNS system in I2P, there different DNS providers federate with each other and share their records.
There are some projects to create decentralized DNS systems, but almost no one uses them, so if you try to use them than you limit amount of your potential users drastically.
Thank you for your work, but why not just use ff2mpv?
TLS clienthello contains unencrypted string, called SNI, that contains the domain of a destination web site. It must be unencrypted to work, because web sites read this string to determine which certificate to use.
You do not break encryption. It is unencrypted by design.
With all due respect, but it seams to me that you do not quite understand how HTTPS works. For encryption it relies on TLS protocol. And TLS does not encrypt everything, it encrypts only payload, but it also has to share some additional data to even establish encrypted connection. The majority of that work is done by exchanging clienthello and serverhello. To do that client has to clarify what server he is even trying to reach as there can be multiple servers on IP, but they have separate certificates, support different cyphers etc. For that a string “SNI”, that contains domain name is used. Only after client and server exchange all the necessary information encrypted conversation can start. So, by looking into clienthello and reading SNI any MITM can determine what web site are you trying to reach.