На ум приходят:

• накладные расходы (тем кому не нужно шифрование придётся делать доп-телодвижения)
• легаси (в момент проектирования стека безопасностью мало кто парился)

Кроме этого, различные vpn как раз на этом уровне и выполняют шифрование, не уверен на 100% но OpenVPN вроде и на L2 это делает. То, что уровень виртуальный, не перемещает его в модели.

А вообще вопрос интересный. Ты бы сюда позвал всяких security и cryptography.

Ценность шифрования в p2p. Где конечной точкой является конкретное приложение конкретного пользователя.

На компе одновременно работают Вася и Вова. Которые общаются в крыпточате с Верой и Викой соответственно, сидящих на разных компах. Шифрование должно быть от Васи до Веры и от Вовы до Вики.

Проще всего шифровать на уровне приложения end to end. А для передачи использовать обычную сеть.

Если создавать шифрование на сетевом уровне, то надо:

1. Создавать два виртуальных крыпто-интерфейса на компе Вовы и Васи.

2. Вешать на них IP.

3. Добавлять маршруты

4. Написать сетевой экран.

В реалиях, между оффисами используется двойное шифрование: шифрованный тунель и приложения свой трафик шифруют независимо.

Зачем вообще нужны протоколы «для шифрования» трафика на прикладном уровне? Почему не предусмотреть шифрование на уровне взаимодействия узлов и/или сеанса связи между узлами (сетевой уровень?)?

Чтобы другие программы, работающие на компе не имели возможность просматривать приватный трафик.

И для соблюдения 24 статьи Конституции РФ.

Чтобы другие программы, работающие на компе не имели возможность просматривать приватный трафик.

Это пока Гугл ещё не захватил весь Интернет. Вот когда захватит, он даст вам единственный «правильный» VPN, в котором он будет сам видеть трафик. А сколько программ будут видеть трафик друг-друга никого не волнует. По причине, что увидеть можно только от админа, который и сейчас может постараться, чтобы увидеть что и как шифруют программы.

По причине, что увидеть можно только от админа, который и сейчас может постараться, чтобы увидеть что и как шифруют программы.

Наличие прав root не дает прямой возможности просматривать приватный трафик между приложениями.

Зачем вообще нужны протоколы «для шифрования» трафика на прикладном уровне?

Для чего эти кавычки? На прикладном нужны потому, что так удобнее и гораздо больше пространства для манёвра, взять хоть тот же SSH.

Почему не предусмотреть шифрование на уровне взаимодействия узлов и/или сеанса связи между узлами (сетевой уровень?)?

Уже ведь есть IPsec. Да и зачем останавливаться на сетевом уровне, если можно сразу использовать физический? А вот зачем:

1) Если принимающая сторона не ожидает зашифрованной информации, то она не пошлёт никакого ответа
2) Стандартизация
3) Чем «ниже» будет шифрование, тем сложнее будет разделять данные. А я напомню, что шифрование само по себе нужно исключительно для защиты информации от неавторизованного доступа. Если всю информацию будут шифровать все одинаковым образом, одними и теми же ключами(на таком низком уровне адекватно использовать только симметричное), то смысла шифроваться не будет вовсе, так как доступ будут иметь все.
4) Наконец, шифровать вообще всё не только бессмысленно, но и вредно - шифрование не только защищает от неавторизованного доступа, но и значительно усложняет(вплоть до полной невозможности) сжатие и\или восстановление части информации(а ни один канал передачи нельзя считать идеальным - потери будут всё равно). Шифровать те же метаданные вредно почти всегда.

Вот даже этих причин хватает, чтобы «выносить» шифрование повыше. Ослабления шифрования при этом не происходит вообще, скорее даже наоборот. На деле оверлейные сети(грубо можно считать, что они «выше» седьмого уровня) защищены куда лучше, чем насквозь шифрованные, при этом сохраняют все достоинства(или почти все)«обычных», а отличить одну оверлейную сеть от другой - нетривиальная задача.

Потому что у криптографии есть разное применение. Потому что на уровнях ниже крипто может не быть.

Наличие прав root не дает прямой возможности просматривать приватный трафик между приложениями.

Потому я и выразился как «может постараться». Взять и пересобрать браузер, который будет сливать трафик и ключи и так далее.

Взять и пересобрать браузер, который будет сливать трафик и ключи и так далее.

А если на компе Integrity включено?

А если на компе Integrity включено?

Понятия не имею. Ещё раз — выдавать за главное преимущество защиту трафика от просмотра хакерскими методами между локальными программами — это просто смешно.

Шифровать те же метаданные вредно почти всегда.

Эта, очень плохая, мысль посетила разрабов текущего протокола HTTPS…

Шифровать надо все и всегда. Если один о тотже админ настраивает оба конца тунеля проблем не будет.

Недавно смотрел:

openswan - подписанный левым ключом openpgp, даже не распаковывал.

libreswan - не смотря на обнадеживающую приставку libre, собирается только с openssl. Для работы хочет ядро с ipv6 и если есть только ipv4 падает.

strongswan - требует для работы много capabolities в строгих изолированных окружения со строгим caps работать не будет. Когда эти программисты начнут административные дела выносить в инит скрипты, а сервисы запускать сразу с привилегиями пользователя и без caps?

С включенным Inregrity, если имея root доступ подменить приложение, то оно не запустится.

С включенным Inregrity, если имея root доступ подменить приложение, то оно не запустится.

Я не знаю о чём это, но совершенно не важно. Если нет пользователя, который может пересобрать окружение, значить это не свободная платформа.

Если нет пользователя, который может пересобрать окружение, значить это не свободная платформа.

Ты не знаешь магии крыптографии.

Пересобрать можно, а ключ потделать нет, или скажем оооочень трудно.

Ты не знаешь магии крыптографии.

Доо, конечно...

а ключ потделать

Зачем?

Зачем?

Иначе Integrity тебя поймает.

Иначе Integrity тебя поймает.

Ну то есть кроме «халва-халва» сказать нечего. Я так и думал.

Ты пятизвездочный ЛОРовец и мне анониму тебя еще учить надо?

Путин с «единой россией» за эту информацию угрожают людям пяти летним строком: Что должен знать специалист ИБ на старте (комментарий)

Федеральный закон от 04.05.2011 N 99-ФЗ (ред. от 02.08.2019) «О лицензировании отдельных видов деятельности»

Статья 12. Перечень видов деятельности, на которые требуются лицензии

1. В соответствии с настоящим Федеральным законом лицензированию подлежат следующие виды деятельности:

1. разработка, производство, распространение шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств, выполнение работ, оказание услуг в области шифрования информации, техническое обслуживание шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств…

«Уголовный кодекс Российской Федерации» от 13.06.1996 N 63-ФЗ (ред. от 02.08.2019)

УК РФ Статья 171. Незаконное предпринимательство

1. Осуществление предпринимательской деятельности без регистрации или без лицензии в случаях, когда такая лицензия обязательна…

2 … принудительными работами на срок до пяти лет, либо лишением свободы на срок до пяти лет …

Спасибо за понятный ответ.

Тогда жаль другое: что протоколы, обеспечивающие связь приложений, пытаются быть частью сетевой модели, что заканчивается не очень хорошо. Это уже не я придумал, но вот не могу найти ту статью… Что HTTP/2 или HTTP/3 перереализовывает часть вещей, лежащих на плечах нижележащих уровней.

Не надо ничего подделывать. Залезть отладчиком и взять cleartext.

Залезть отладчиком и взять cleartext.

Из какого, извените, места взять?

Речь идет о технологиях верификации целосности Linux используемых в системах Integrity.

В памяти процесса присутствует cleartext и его можно оттуда взять.

Использование крипто «от Васи и от Вовы» препятствует извлечению сообщений из пакетов, но не мешает делать это между вводом/выводом и отправкой/получением.

И речь идёт о том зачем использовать крипто на разных уровнях. «Системы интегрити» вы сюда сами приплели. Приторговываете?

Нынешние архитектуры ОС устраивают службы безопасности всех стран.

Не сложно создать архитектуру ОС, которую ни кто не взломает.
Способов много, но это ни кто не разрешит внедрять.

Спорить ни с кем не буду.

Ныне лишь имитация безопасности и скорее средство заставить клиентов раскошеливаться почаще.

Не сложно создать архитектуру ОС, которую ни кто не взломает.

ни кто

Особенно, если в школе плохо учились.

Рассказ на тему - http://samlib.ru/b/bykow_walerij_alekseewich/forstoperrors.shtml

Кроме бросания «какашек» еще чего-нибудь умеете?

Согласен с тем, что с моей стороны это вброс.

Ты понял, что в рабочей системе GNU/Linux присутствуют только публичные ключи, которых для верификации целостности хватает, а для подписи файла в Integrity необходим приватный которого нет.

В памяти процесса присутствует cleartext и его можно оттуда взять.

https://en.m.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Proc_restrictions

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/security/yama/Kconfig

#CONFIG_DEVMEM is not set

Как Вове достать ключ с процесса Васи? Доступ Вовы к областям памяти используемыми процессами Васи, - закрыт.

Если Вова на машине хозяин, а Вася – раб, то Васиного мнения о том что и как на машине запущено и кто куда имеет доступ никто не спрашивает. Вове при этом защищать свои коммуникации с Верой (или с кем он там…) от Васи на уровне машины вовсе необязательно, поскольку лишенец Вася доступа никуда не имеет.

покажи плз этому противному анону как это работает, а то он свято верит что рут - не рут и есть заклятья, которые не позволяют руту быть хозяином хоста и любого процесса, в том числе смотреть в него.

И чем это поможет против end to end? Одним из основ всего IT является виртуализация в широком смысле этого слова, например, когда крипта пакуется друг в друга как матрёшка.

Наконец, шифровать вообще всё не только бессмысленно, но и вредно - шифрование не только защищает от неавторизованного доступа, но и значительно усложняет(вплоть до полной невозможности) сжатие и\или восстановление части информации(а ни один канал передачи нельзя считать идеальным - потери будут всё равно). Шифровать те же метаданные вредно почти всегда.

Тебя тоже в список вредителей надо внести, или просто технически не подкован? Если тебе надо от помех защищаться, то не поможет тебе не шифрованный трафик, код рида-соломона поможет, а ему пофигу что там кодировать - он с потоком байт работает.

Вова и Вася обычные пользователи.

Прочти внимательно еще раз:

https://www.linux.org.ru/add_comment.jsp?topic=15616630&replyto=15620072

Для соблюдения 23 статьи Конституции РФ шифрования должно применятся между конечными приложениями пользователей (end to end).

Подмене приложения, используя права root, можно противостоять:

Глупый вопрос: зачем изобретается криптография на разных уровнях сетевой модели (комментарий)

Вопрос к "отличникам" ЛОРа

рут - не рут и есть заклятья, которые не позволяют руту быть хозяином хоста и любого процесса, в том числе смотреть в него.

Ты единственный оставшийся на ЛОРе двоечник, который ничего не знает о Мандатном Контроле Доступа (MAC). И как с его помощью ограничить права пользователя root. Есть еще в ядре Linux технология capabilities, с помощью которой можно сбросить права root процесса.

А теперь вопрос к «отличникам» ЛОРа:

Какое название «заклятого дистрибутива» GNU/Linux в котором «рут - не рут и ядро не позволяет руту быть хозяином хоста и любого процесса, в том числе смотреть в него, смотреть в домашние каталоги пользователей: /home/vova, /home/vasya»? Кем разрабатывается и где используется этот «заклятый дистрибутив» GNU/Linux? С помощью каких технологий в нем ограничены права пользователя root?[\b]

«Всю жизнь чего-то мне недоставало.
Чего? - не думал я. И вдруг опомнился:
Всё-всё мне Конституция давала
А я прошёл
И с ней не познакомился!»

Неужто внесли поправку в конституцию и прям так и написали: «шифрования должно применяться между конечными приложениями пользователей»?

Не надо путать длинное с зелёным.
«Чтобы Вова не подсмотрел трафик Васи на том же компьютере» — это не причина для шифрования на уровне приложения.
Существование мандатного доступа не означает того, что все системы его имеют и/или используют.
Наличие мандатного доступа позволяет решить проблему «Вова может подсмотреть в трафик Васи на том же компьютере» без использования шифрования на уровне приложения.

Сиди дома. Соблюдай. Необходимо. Достаточно.

прикладной уровень контролировать проще. сам колхозишь и сам контролируешь. если ты чтото не контролируешь то лучше иметь это в виду. ты полюбас не сможешь контролировать узел. даже если не будешь спать совсем. тебе придётся делегировать полномочия. чтобы делегировать, нужен уровень доверенности. а это уже прикладной уровень. понимаешь?

Не охота отвечать.

«Чтобы Вова не подсмотрел трафик Васи на том же компьютере» — это не причина для шифрования на уровне приложения.

повод.

если условный вася не захочет чтобы условный вова подсматривал его трафик то трафика условный вова не увидит. даже не догадается что он есть. условный вася может доверяться условному вове до какого угодно уровня но если их не связывают некие ментальные приоритеты любой уровень взаимопроникновения заканчивается на раздватри. это уровень узлового шифрования. интересы серьёзные и люди серьёзные. как только условный вова начинает думать что он бог и ему можно всё, правильный трафик начинает тотально шифроваться и условный вова начинает видеть левый. например какойнибудь прон. или новостную ленту которую читают только пенсы или укурки.

Зачем вообще нужны протоколы «для шифрования» трафика на прикладном уровне?

Что бы зашифровать трафик приложения. Искренне ваш, Кэп.

Почему не предусмотреть шифрование на уровне взаимодействия узлов и/или сеанса связи между узлами (сетевой уровень?)?

L3-VPN есть, и успешно выполняет свои задачи.

Если твой вопрос, почему бы просто не оставить криптографию на L3 и не страдать, то ответов несколько:

• Логическая изоляция данных друг от друга. У тебя весь трафик будет шифроваться только одним ключом, что не есть хорошо

• Шифровать весь трафик может быть и не нужно. Да, это можно решить путем настройки split-туннелей, но у этого решения тоже есть свои минусы

• Аутентификация. TLS позволяет настроить свою аутентификацию для каждого используемого приложения, что может быть нужно

Наличие прав root не дает прямой возможности просматривать приватный трафик между приложениями.

Дампишь память, ищешь ключи, параллельно записываешь весь трафик, чтобы в будущем расшифровать.

Дампишь память, ищешь ключи,

#CONFIG_DEVMEM is not set

Чо, и ptrace не заработает?

А ты проверь. Добавить еще можно:

#CONFIG_DEVKMEM is not set
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y
CONFIG_GRKERNSEC_AUDIT_PTRACE=y
CONFIG_GRKERNSEC_HARDEN_PTRACE=y
CONFIG_GRKERNSEC_PTRACE_READEXEC=y

Можно и права давать 511 (r-x--x--x) на те проги что с приватными ключами работают.

Простой пример.

client <- link1 -> router <- link2 -> server.

Шифрование на сетевом уровне будет работать только на link1. По link2 либо вообще не будет шифрования, либо будет отдельная шифрованная линия между router и server. В первом случае кто угодно, перехвативший поток на link2, сможет получитьдоступ к данным, во втором злоумышленник на router может получить доступ.

Если же делать шифрование на уровне application, оно будет сквозное client-server.

Это не так бессмысленно если владельцу router надо быть уверенным что как client подключился именно тот, кто подписал договор на получение услуги доступа к интернету.

Это уже другой вопрос. ТС спросил, зачем нужно шифрование прикладного уровня. Вот именно для того, что я описал. Это не отменяет того, что шифрование на более низких уровнях тоже нужно во многих случаях.

и ptrace не заработает?

ptrace закрыть всем вообще наглухо!

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/LSM/Yama.rst [pre] CONFIG_SECURITY=y CONFIG_SECURITY_YAMA=y [/pre] echo 3 >/proc/sys/kernel/yama

И подправить /etc/sysctl.conf чтобы при перезагрузки компа настройки сохранились: [pre] kernel.yama = 3 [/pre]

и ptrace не заработает?

ptrace закрыть всем вообще наглухо!

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Docum...

CONFIG_SECURITY=y
CONFIG_SECURITY_YAMA=y

И подправить /etc/sysctl.conf чтобы при перезагрузки компа настройки сохранились:

kernel.yama = 3