У меня нет информации о том как большинство его использует. Цензор тут притом, что мы находимся в ветке комментариев, которая началась с цепочки комментариев: - Я считаю Yggdrasil будущим в текущих реалиях блокировок - Его заблокируют легко - Как заблокируют? - Я ответил на вопрос как
К тому же глобальный публичный Yggdrasil это не единственный возможный способ эксплуатации Yggdrasil.
Если соединение замаскировано под обычное TLS-соединение то конечно такая блокировка вызовет сопутствующий ущерб, но для цензора это уже не будет выглядеть как Yggdrasil-соединение.
>Как забанят. По TLS-фингерпринту. Сертификаты с ed25519 и обычный Go TLS стек позволят заблокировать Yggdrasil без сопутствующего ущерба для обычных TLS-соединений.
По статистике трафика. Она очень сильно отличается у настоящего веб-сервера и скрытого ретранслятора. Может получится это спрятать разделением потоков в xhttp используя два разных сервера: один для исходящего трафика, другой для входящего.
Это возможно. Но это нерелевантно в контексте статьи, которая призывает строить публичную mesh-сеть на основе Yggdrasil. В своей приватной mesh-сети можно конечно сделать что угодно.
Yggdrasil использует x509-сертификаты с ed25519 вместо RSA или ECDSA. Популярные браузеры должны принимать эти алгоритмы, но публичным центрам сертификации не разрешено выпускать сертификаты с ed25519:
6.1.5 Key sizes
For RSA key pairs the CA SHALL:
• Ensure that the modulus size, when encoded, is at least 2048 bits, and;
• Ensure that the modulus size, in bits, is evenly divisible by 8.
For ECDSA key pairs, the CA SHALL:
• Ensure that the key represents a valid point on the NIST P‐256, NIST P‐384 or NIST P‐521
elliptic curve.
No other algorithms or key sizes are permitted.
В чём именно заключается маскировка Yggdrasil под обычный трафик? Yggdrasil использует ed25519 x509-сертификаты. Ни один браузер такие не использует согласно требованиям CA/B форума. Это позволяет легко заблокировать Yggdrasil трафик замедляя соединения со всеми ServerHello с ed25519-сертификатами без последствий для обычных сайтов.
Потому что это чья-то отсебятина, которую копируют по цепочке из статьи в статью по этой проблеме. В коммите фикса ни слова о каком-либо бренде или вообще типе накопителя.
Для воспроизведения проблемы достаточно было иметь device mapper-based блочное устройство, поддерживающее TRIM, у которого непоследовательно были расположены блоки, например LV с количеством сегментов более одного. Иными словами фрагментированные LV и thin-provisioned тома могли быть так же повреждены даже если они лежали на жёстких дисках.
Я правильно понимаю, что зарезервированный диапазон (for future use) 240.0.0.0/4 не используют из-за того что много оборудования не будет с ним работать или есть какая-то другая причина?
У меня нет информации о том как большинство его использует. Цензор тут притом, что мы находимся в ветке комментариев, которая началась с цепочки комментариев:
- Я считаю Yggdrasil будущим в текущих реалиях блокировок
- Его заблокируют легко
- Как заблокируют?
- Я ответил на вопрос как
К тому же глобальный публичный Yggdrasil это не единственный возможный способ эксплуатации Yggdrasil.
Если соединение замаскировано под обычное TLS-соединение то конечно такая блокировка вызовет сопутствующий ущерб, но для цензора это уже не будет выглядеть как Yggdrasil-соединение.
>Как забанят.
По TLS-фингерпринту. Сертификаты с ed25519 и обычный Go TLS стек позволят заблокировать Yggdrasil без сопутствующего ущерба для обычных TLS-соединений.
Хотя не, протупил. Разделение ничего не изменит.
По статистике трафика. Она очень сильно отличается у настоящего веб-сервера и скрытого ретранслятора. Может получится это спрятать разделением потоков в xhttp используя два разных сервера: один для исходящего трафика, другой для входящего.
Нет, это прямое следствие стандартизации. Разрешено то, что было оценено и проверено на пригодность.
Это возможно. Но это нерелевантно в контексте статьи, которая призывает строить публичную mesh-сеть на основе Yggdrasil. В своей приватной mesh-сети можно конечно сделать что угодно.
Yggdrasil использует x509-сертификаты с ed25519 вместо RSA или ECDSA. Популярные браузеры должны принимать эти алгоритмы, но публичным центрам сертификации не разрешено выпускать сертификаты с ed25519:
Источник: https://cabforum.org/working-groups/server/baseline-requirements/documents/CA-Browser-Forum-TLS-BR-2.2.5.pdf
Из-за этого сейчас заморожен этот запрос в Let's Encrypt: https://community.letsencrypt.org/t/support-ed25519-and-ed448/69868
Такие соединения РКН может заблокировать без ущерба для обычных TLS-соединений.
Да, мимикрировать под что-то правдоподобное, тот же naive proxy. Либо как предложил litalen спрятать это в вебсокетах сайта.
В чём именно заключается маскировка Yggdrasil под обычный трафик? Yggdrasil использует ed25519 x509-сертификаты. Ни один браузер такие не использует согласно требованиям CA/B форума. Это позволяет легко заблокировать Yggdrasil трафик замедляя соединения со всеми ServerHello с ed25519-сертификатами без последствий для обычных сайтов.
Трафик Yggdrasil очень легко отличить от обычного TLS-трафика. Если посмотреть на его трафик в Wireshark то отличия очевидны.
Я не вижу смысла призывать здесь делать на его основе публичную mesh-сеть. РКН заблокирует его моментально как только обратит на него внимание.
Doka 2 https://www.youtube.com/watch?v=Xf-8anqrIJ4
929 Chris Mason <chris.mason@oracle.com>655 David Sterba <dsterba@suse.com>
394 Linus Torvalds <torvalds@linux-foundation.org>
392 Nikolay Borisov <nborisov@suse.com>
357 Filipe Manana <fdmanana@suse.com>
312 Liu Bo <bo.li.liu@oracle.com>
312 Miao Xie <miaox@cn.fujitsu.com>
303 Josef Bacik <josef@redhat.com>
265 Josef Bacik <jbacik@fusionio.com>
208 Anand Jain <anand.jain@oracle.com>
205 David Sterba <dsterba@suse.cz>
155 Qu Wenruo <wqu@suse.com>
147 Jeff Mahoney <jeffm@suse.com>
147 Qu Wenruo <quwenruo@cn.fujitsu.com>
142 Josef Bacik <jbacik@fb.com>
128 Al Viro <viro@zeniv.linux.org.uk>
113 Chris Mason <clm@fb.com>
105 Stefan Behrens <sbehrens@giantdisaster.de>
Для воспроизведения проблемы достаточно было иметь device mapper-based блочное устройство, поддерживающее TRIM, у которого непоследовательно были расположены блоки, например LV с количеством сегментов более одного. Иными словами фрагментированные LV и thin-provisioned тома могли быть так же повреждены даже если они лежали на жёстких дисках.
Начиная с версии 2.4 есть в виде опции tls-crypt (не путать с tls-auth), которая обфусцирует TLS-хендшейк: https://github.com/OpenVPN/openvpn/blob/master/doc/tls-crypt-v2.txt
Проверил что происходит дальше:

Если нажать кнопку то отображается это:
Кнопка Reset account не активна.
На почту приходит такое письмо:


На сам аккаунт телеграма приходит такое сообщение:
Какова гарантия, что эти действия повредят непосредственно чипы с информацией, а не просто сожгут интерфейс подключения?