Вариант для распечатки		Пред. тема | След. тема
Форум Информационная безопасность (ПО для увеличения безопасности)
Изначальное сообщение		[ Отслеживать ]

"TCP-S: шифрование трафика на 4 уровне модели OSI."	+/–
Сообщение от Luis (ok), 04-Май-26, 16:06
Всем привет. Я давно озадачился вопросом о том, как избавить себя от трудозатрат на внедрение систем централизованного управления сертификатами, дополнив существующий транспорт протокола TCP/IP - шифрованием. Мы знаем что, весь маршрут с точки зрения наблюдателя обозримой среды, смотрится и анализируется, где каждый может просматривать содержимое условных единиц на содержание и для каждой единицы нужны методы сокрытия информации. В итоге и получилось решение в виде модуля расширения надстройки протокола tcp, используя netfilter хуки LOCAL_OUT и PRE_ROUTING, прозрачно шифруя вообще все TCP-сокеты на хосте, при условии установки модуля на клиент и сервер - и весь трафик между ними автоматически идёт в криптованном виде, что даёт преимущество по времени эффективности решения задачи для целей пресечения демаскированию данных. Протокол интегрируется прямо в TCP-рукопожатие, используя кастомные TCP-опции (kind=253): * SYN-пакеты несут 36-байтовую TC-опцию с эфемерным публичным ключом X25519. * SYN-ACK возвращает такую же опцию с публичным ключом сервера. * После обмена ключами через ECDH (X25519) вычисляется общий секрет, из которого по методу HKDF-Expand выводятся четыре ключа: enc_c2s / enc_s2c / mac_c2s / mac_s2c. * Все TCP-данные шифруются поточным шифром ChaCha20, размер пакета не меняется. * Каждый пакет с данными или FIN содержит Poly1305 MAC в виде TM-опции (20 байт). Ключ для Poly1305 уникален для каждого пакета и вычисляется из позиции в потоке, а MAC-токен покрывает флаги TCP — защита от подмены флагов и инъекции пакетов. После установки шифрованного канала происходит аутентификация по модели TOFU (Trust On First Use): статический identity-ключ (генерируется при загрузке модуля, хранится только в RAM) верифицируется через auth_tag. При первом соединении публичный ключ пира запоминается в кеше (IP → pubkey), при последующих сверяется. Несовпадение или неверный auth_tag — MITM-атака → пакет дропается. Безопасность и защита от downgrade-атак: * Forward secrecy: эфемерные ключи уничтожаются (memzero_explicit) сразу после деривации сессионных. * Downgrade-защита: параметр enforce=1 заставляет модуль дропать любые non-TCPS соединения (SYN без TC-опции). Без этого — fallback к обычному TCP для совместимости. * RST injection: входящие RST-пакеты в зашифрованном состоянии игнорируются, соединение разрывается только через FIN или GC timeout. * Timing-атаки: сравнение MAC через crypto_memneq (constant-time). * Отсутствие зависимости от OpenSSL: вся криптография на kernel crypto API (libcurve25519) и собственной реализации Poly1305 на 26-битных лимбах. Ограничения: * IPv4 only (IPv6 пока не поддерживается). * TOFU при первом соединении — как SSH, доверие без верификации. Для критичных сценариев рекомендуется сверить fingerprint через dmesg. * Лимит в 4096 одновременных соединений. * auth_tag 4 байта (32-битная безопасность для identity verification). * Pure ACK не аутентифицируются (нет MAC). Модуль работает на arm64 и amd64. После загрузки любое TCP-соединение между хостами с модулем автоматически шифруется, будь то PostgreSQL, HTTP или SSH. Проверить работу можно через dmesg | grep tcps или tcpdump: SYN-пакеты будут содержать unknown-253 опции, а payload станет нечитаемым. Репозиторий: https://github.com/Last-Guy-In-Stars/TCP-S Лицензия MIT, так что форкайте, экспериментируйте и используйте на своё усмотрение.
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. Скрыто модератором	+1 +/–
Сообщение от Аноним1234 (?), 04-Май-26, 17:18
Ничего не понял. Если товарищь маор на своём роутере будет дешифровывать, анализировать и далее шифровать то всё будет работать как вами и задуманно?
Ответить | Правка | Наверх | Cообщить модератору

	2. Скрыто модератором	+/–
	Сообщение от Luis (ok), 04-Май-26, 19:15
	> Ничего не понял. Если товарищь маор на своём роутере будет дешифровывать, анализировать > и далее шифровать то всё будет работать как вами и задуманно? Спасибо за вопрос, отвечаю просто: как суперпозиция, да и нет, дело в том что в модуле TCP-S реализован подход с применением подхода TOFU + auth_tag - статические ключи(fingerprint) и если Майор установил модуль на роутер и мы соединяемся впервые, тогда Майор сможет встать между клиентом и сервером, управляя их данными. Это точно такая же уязвимость, как и при первом подключении по SSH, если мы не сверим отпечатки ключей по защищенному каналу, то есть риск подключится к Майору - мошеннику. Атака называется - активной подменой. То есть: 1. Роутер просто пропускает через себя трафик(он собственно шлюз), он не сможет трафик дешифровать, так как ключи шифрования(ChaCha20) вычисляются только на конечных хостах через обмен эфемерными ключами X25519(Diffie-Hellman). По итогу роутер Майора видит только зашифрованный трафик 2. Для дешифрования трафика, анализа и шифрование далее, Майору надо установить на роутер модуль TCP-S и активно притворяться конечным сервером и обратно клиентом, разрывая TCP-сессию на две части. 3. Защита от второго пункта реализована TOFU+auth_tag: при первой связи, если не проверить отпечаток пальца ключа вручную, атака возможна. Но при всех последующих - если роутер Майора подменит ключ, модуль TCP-S обнаружит несовпадение статического ключа или неверный auth_tag(для подделки которого нужен приватный ключ настоящего сервера) и заблокирует соединение.
	Ответить | Правка | Наверх | Cообщить модератору

3. "TCP-S: шифрование трафика на 4 уровне модели OSI."	+/–
Сообщение от Tron is Whistling (?), 04-Май-26, 22:30
>>> После установки шифрованного канала происходит аутентификация по модели TOFU (Trust On First Use): статический identity-ключ (генерируется при загрузке модуля, хранится только в RAM) То есть если удалённую ноду перезагрузили - всё, привет?
Ответить | Правка | Наверх | Cообщить модератору

	5. "TCP-S: шифрование трафика на 4 уровне модели OSI."	+/–
	Сообщение от Luis (ok), 04-Май-26, 23:06
	>>>> После установки шифрованного канала происходит аутентификация по модели TOFU (Trust On First Use): статический identity-ключ (генерируется при загрузке модуля, хранится только в RAM) > То есть если удалённую ноду перезагрузили - всё, привет? Это классический компромисс: мы получаем стойкость ключей к компрометации диска, но получаем неработоспособность системы при любой перезагрузке ноды без синхронного сброса кешей у всех участников. В отличие от SSH, где ключи персистентны, TCP-S требует ручной "реанимации" сети после рестарта. Храня ключ только в RAM, остаётся гарантирует: как только сервер выключили — ключа больше нет. Никто не сможет притвориться этим сервером в будущем и расшифровать прошлые сессии, даже если изымут железо. Спасибо за замечание.
	Ответить | Правка | Наверх | Cообщить модератору

	10. "TCP-S: шифрование трафика на 4 уровне модели OSI."	+/–
	Сообщение от Tron is Whistling (?), 05-Май-26, 09:51
	Да не за что. Всё-таки необходимы фильтр того, что шифруем (ну, селектор по src/dst net), и какие-то дополнительные ухищрения: либо преаутентификацию на прешаре/сертификатах, либо ещё что-то. Потому что иначе да, очень легко MITM вкроить.
	Ответить | Правка | Наверх | Cообщить модератору

	12. "TCP-S: шифрование трафика на 4 уровне модели OSI."	+1 +/–
	Сообщение от Luis (ok), 05-Май-26, 11:05
	> Да не за что. > Всё-таки необходимы фильтр того, что шифруем (ну, селектор по src/dst net), и > какие-то дополнительные ухищрения: либо преаутентификацию на прешаре/сертификатах, > либо ещё что-то. Потому что иначе да, очень легко MITM вкроить. Исправил поведение при перезагрузке модуля (epoch): 1. При каждой загрузке модуля генерируется: * Новый статический identity-ключ (fingerprint меняется) * Случайный 32-битный epoch (передаётся в TC option) 2. TOFU-кеш при несовпадении pubkey: * Epoch    Реакция * Тоже другой    Ротация (перезагрузка) — auto-accept при auto_rotate=1 * Тот же самый    MITM — дроп 3. При auto_rotate=0 — любая смена ключа = MITM, обе стороны должны перезагрузить модуль одновременно.
	Ответить | Правка | Наверх | Cообщить модератору

4. "TCP-S: шифрование трафика на 4 уровне модели OSI."	+/–
Сообщение от Tron is Whistling (?), 04-Май-26, 22:32
Дальше, если опцию 253 посерёдке срезать - что будет?
Ответить | Правка | Наверх | Cообщить модератору

	6. "TCP-S: шифрование трафика на 4 уровне модели OSI."	+/–
	Сообщение от Luis (ok), 04-Май-26, 23:10
	> Дальше, если опцию 253 посерёдке срезать - что будет? Опции 253 и 254 — экспериментальные и это эффективная атака на соединение TCP-S, которая приводит к его разрыву или откату к незашифрованному TCP. Это прямое следствие использования экспериментальных опций в среде, где промежуточные устройства могут их модифицировать. Спасибо за Ваше замечание, взял на раздумие.
	Ответить | Правка | Наверх | Cообщить модератору

	11. "TCP-S: шифрование трафика на 4 уровне модели OSI."	+/–
	Сообщение от Tron is Whistling (?), 05-Май-26, 09:52
	Да, таки фильтр src/dst net неизбежен здесь, потому что иначе получается даунгрейд.
	Ответить | Правка | Наверх | Cообщить модератору

	13. "TCP-S: шифрование трафика на 4 уровне модели OSI."	+1 +/–
	Сообщение от Luis (ok), 05-Май-26, 11:08
	> Да, таки фильтр src/dst net неизбежен здесь, потому что иначе получается даунгрейд. Исправил разрыв 253-соединения (downgrade), раньше: если TC/TM/TI option не добавился → NF_ACCEPT → откат к plaintext (downgrade-уязвимость). Теперь: всё дропается (NF_DROP): Ситуация: * SYN+ACK без TCPS option (модуля нет на сервере) * Не удалось добавить TC в SYN * Не удалось добавить TI в pure ACK * Не удалось добавить TM в data * SYN без TCPS на сервере при enforce=1 Соединение либо зашифровано, либо не существует — plaintext fallback исключён. При этом FULL Mode канал работает по избирательному подходу используя TOFU кэш как таблицу клиентов для регистрации с кем общаться через модуль а где без него, что позволяет оставаться много классовой иерархии сетей. В целом думаю переделать общение между клиентами для сохранения целостности используя дерево Меркла.
	Ответить | Правка | Наверх | Cообщить модератору

	7. "TCP-S: шифрование трафика на 4 уровне модели OSI."	+/–
	Сообщение от Аноним (7), 05-Май-26, 01:53
	> Дальше, если опцию 253 посерёдке срезать - что будет? Наверно тоже самое, что и посерёдке повредить пакет, подменить IP, присунуть сертификат и тд. Это не маршрутизатора ума дело - лезть выше IP (хотя фаерволлы так часто делают, да).
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

8. "TCP-S: шифрование трафика на 4 уровне модели OSI."	+/–
Сообщение от pavel_simple. (?), 05-Май-26, 09:07
> Я давно озадачился вопросом о том, как избавить себя от трудозатрат на > внедрение систем централизованного управления сертификатами, дополнив существующий > транспорт протокола TCP/IP - шифрованием. и получил стандартную проблему MiTM. Кроме того, зачем эти изыски с шифрованием в ядре, если достаточно подгрузить через LD_PRELOAD необходимые хуки и забыть этот ужас
Ответить | Правка | Наверх | Cообщить модератору

	9. "TCP-S: шифрование трафика на 4 уровне модели OSI."	+/–
	Сообщение от Luis (ok), 05-Май-26, 09:24
	>> Я давно озадачился вопросом о том, как избавить себя от трудозатрат на >> внедрение систем централизованного управления сертификатами, дополнив существующий >> транспорт протокола TCP/IP - шифрованием. > и получил стандартную проблему MiTM. Кроме того, зачем эти изыски с шифрованием > в ядре, если достаточно подгрузить через LD_PRELOAD необходимые хуки и забыть > этот ужас Здравствуйте) 1. Через LD_PRELOAD сделать прозрачное шифрование всего трафика невозможно, так как: 1.1. Системные службы как например SSH могут не использовать динамические библиотеки или использовать другие.   Если возможно, в студию решение, что просто так языком трепать? 2. LD_PRELOAD вроде не умеет добавлять криптографическую защиту и опции TCP пакетов, которые проходят через ядро. 3. LD_PRELOAD управлять сложнее, что приводит к трудноуловимым проблемам, тогда как модуль ядра, при правильной реализации, обеспечивает более стабильное и предсказуемое поведение. 4. LD_PRELOAD - это инструмент отладки, тестирования и модификации приложений и использовать такой подход для системы безопасности, для меня является полным абсурдом и строительством дома на песке. 5. Внимательней ознакомьтесь с проектом, в текущей реализации MITM возможен только при первом соединении.
	Ответить | Правка | Наверх | Cообщить модератору

	15. "TCP-S: шифрование трафика на 4 уровне модели OSI."	+/–
	Сообщение от pavel_simple. (?), 06-Май-26, 09:41
	>[оверквотинг удален] > Если возможно, в студию решение, что просто так языком трепать? > 2. LD_PRELOAD вроде не умеет добавлять криптографическую защиту и опции TCP пакетов, > которые проходят через ядро. > 3. LD_PRELOAD управлять сложнее, что приводит к трудноуловимым проблемам, тогда как модуль > ядра, при правильной реализации, обеспечивает более стабильное и предсказуемое поведение. > 4. LD_PRELOAD - это инструмент отладки, тестирования и модификации приложений и использовать > такой подход для системы безопасности, для меня является полным абсурдом и > строительством дома на песке. > 5. Внимательней ознакомьтесь с проектом, в текущей реализации MITM возможен только при > первом соединении. во первых, проблема которая была озвучена (избавится от управления сертификатами) не решена. во вторых, никому не нужно полное шифрование сделаное через netfilter, потому-что для этого есть ipsec, который любой трафик может в тунель засунуть а не только TCP. А если не шифровать весь трафик -- то LD_PRELOAD/IP_TRANSPARENT и реализация в юзерспейсе спасёт от кривых ручкав. в третих, криптографическая защита добавленная в качестве опций TCP -- глупость
	Ответить | Правка | Наверх | Cообщить модератору

	17. "TCP-S: шифрование трафика на 4 уровне модели OSI."	+/–
	Сообщение от Luis (ok), 06-Май-26, 10:27
	>[оверквотинг удален] >> такой подход для системы безопасности, для меня является полным абсурдом и >> строительством дома на песке. >> 5. Внимательней ознакомьтесь с проектом, в текущей реализации MITM возможен только при >> первом соединении. > во первых, проблема которая была озвучена (избавится от управления сертификатами) не решена. > во вторых, никому не нужно полное шифрование сделаное через netfilter, потому-что для > этого есть ipsec, который любой трафик может в тунель засунуть а > не только TCP. А если не шифровать весь трафик -- то > LD_PRELOAD/IP_TRANSPARENT и реализация в юзерспейсе спасёт от кривых ручкав. > в третих, криптографическая защита добавленная в качестве опций TCP -- глупость Здравствуйте) Я буду с Вами как с клинически одарённым Человеком общаться и это моё одолжение для Вас: 1. Вы сертификатами не управляете, модуль сам всё делает и на более легковесных решениях и для всех приложений. 2. Отвечать за всех - дурная привычка, поумерьте значимость своего мнения. 3. И для особо не внимательных: LD_PRELOAD и IP_TRANSPARENT — это инструменты для совершенно других задач (отладка и проксирование), которые не могут обеспечить эквивалентный уровень безопасности и прозрачности. 4. Создайте своё решение.
	Ответить | Правка | Наверх | Cообщить модератору

	20. "TCP-S: шифрование трафика на 4 уровне модели OSI."	+/–
	Сообщение от pavel_simple. (?), 06-Май-26, 10:51
	> Здравствуйте) > Я буду с Вами как с клинически одарённым Человеком общаться и это > моё одолжение для Вас: нет аргументов -- начинай хамить© > 1. Вы сертификатами не управляете, модуль сам всё делает и на более > легковесных решениях и для всех приложений. что делает то? Как защищает от MiTM? > 2. Отвечать за всех - дурная привычка, поумерьте значимость своего мнения. я отвечаю не за всех, а за глупость решения через netfilter. Почему не через tc? Почему не через тунелирование? > 3. И для особо не внимательных: LD_PRELOAD и IP_TRANSPARENT — это инструменты > для совершенно других задач (отладка и проксирование), которые не могут обеспечить > эквивалентный уровень безопасности и прозрачности. да ладно? А чем решение через транспарент сокет или LD_PRELOAD менее безопасно? > 4. Создайте своё решение. сперва добейся!© сколько тебе годиков, ну, так чтобы я понимал откуда такая демагогия примитивная. Замечательное решение, лучшее. Но, пользоваться, конечно таким я не буду
	Ответить | Правка | Наверх | Cообщить модератору

	21. "TCP-S: шифрование трафика на 4 уровне модели OSI."	+/–
	Сообщение от Luis (ok), 06-Май-26, 11:03
	>[оверквотинг удален] > я отвечаю не за всех, а за глупость решения через netfilter. Почему > не через tc? Почему не через тунелирование? >> 3. И для особо не внимательных: LD_PRELOAD и IP_TRANSPARENT — это инструменты >> для совершенно других задач (отладка и проксирование), которые не могут обеспечить >> эквивалентный уровень безопасности и прозрачности. > да ладно? А чем решение через транспарент сокет или LD_PRELOAD менее безопасно? >> 4. Создайте своё решение. > сперва добейся!© сколько тебе годиков, ну, так чтобы я понимал откуда такая > демагогия примитивная. > Замечательное решение, лучшее. Но, пользоваться, конечно таким я не буду Слушай мужик, не делай мне голову, я максимально открыт к здравомыслящим обоснованным выводам. У тебя есть несколько вариантов: 1. Мы встречаемся и ты мне показываешь пользу от дельты возрастной, если она есть. 2. Вы проходите мимо и делаете так как Вам удобно, мой проект можно скачать и переделать под свой лад, успехов в Вашем освоении криптографии и внимательным подходом к решению. 3. Кто ты такой, что бы мне перед тобой держать ответ, что сделал для общества и какую пользу принёс для общества? Почему я должен руководствоваться твоими взглядами? 4. Не пользуйтесь, это право то Ваше.
	Ответить | Правка | Наверх | Cообщить модератору

	16. "TCP-S: шифрование трафика на 4 уровне модели OSI."	+/–
	Сообщение от pavel_simple. (?), 06-Май-26, 09:44
	> 5. Внимательней ознакомьтесь с проектом, в текущей реализации MITM возможен только при > первом соединении. и чем это отличается от trusted CA? Повышенным уровнем геморойя?
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	18. "TCP-S: шифрование трафика на 4 уровне модели OSI."	+/–
	Сообщение от Luis (ok), 06-Май-26, 10:29
	>> 5. Внимательней ознакомьтесь с проектом, в текущей реализации MITM возможен только при >> первом соединении. > и чем это отличается от trusted CA? Повышенным уровнем геморойя? В моей предистории сложность для меня постоянно интерполировать разными CA/SUBCA, что в итоге моё решение стремится избавить от подобных затрат.
	Ответить | Правка | Наверх | Cообщить модератору

	19. "TCP-S: шифрование трафика на 4 уровне модели OSI."	+/–
	Сообщение от pavel_simple. (?), 06-Май-26, 10:47
	> В моей предистории сложность для меня постоянно интерполировать разными CA/SUBCA, что в > итоге моё решение стремится избавить от подобных затрат. как?
	Ответить | Правка | Наверх | Cообщить модератору

	22. "TCP-S: шифрование трафика на 4 уровне модели OSI."	+/–
	Сообщение от Luis (ok), 06-Май-26, 11:04
	>> В моей предистории сложность для меня постоянно интерполировать разными CA/SUBCA, что в >> итоге моё решение стремится избавить от подобных затрат. > как? В описании) переходите по ссылке на репозитория и изучайте документацию.
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема