Pull to refresh
4
Дмитрий@demfloro

Tinker

1
Subscribers
Send message

У меня нет информации о том как большинство его использует. Цензор тут притом, что мы находимся в ветке комментариев, которая началась с цепочки комментариев:
- Я считаю 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.

Источник: 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-сеть. РКН заблокирует его моментально как только обратит на него внимание.

Red Hat её особо и не разрабатывала последние годы, Её активно разрабатывает SUSE как минимум с 2014-го.
git shortlog -sne -- fs/btrfs/
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 тома могли быть так же повреждены даже если они лежали на жёстких дисках.
Я правильно понимаю, что зарезервированный диапазон (for future use) 240.0.0.0/4 не используют из-за того что много оборудования не будет с ним работать или есть какая-то другая причина?
У OpenVPN нет никакого стелс-режима, насколько мне известно.

Начиная с версии 2.4 есть в виде опции tls-crypt (не путать с tls-auth), которая обфусцирует TLS-хендшейк: https://github.com/OpenVPN/openvpn/blob/master/doc/tls-crypt-v2.txt

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


На почту приходит такое письмо:
image
На сам аккаунт телеграма приходит такое сообщение:
image

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

Information

Rating
Does not participate
Registered
Activity