Исходное сообщение
"В Chrome планируют помечать соединение как небезопасное при ..." Отправлено Xaionaro, 16-Дек-14 09:15
>> Это почему ещё? > Потому что очередной сложный в устройстве и конфигурации протокол Что такое «сложный в конфигурации» протокол? И мне не кажется IPSec сложным в устройстве по той причине, что там нет ничего лишнего. Если в случае каких-то других решений всё пакуют в один хрен-разберёшь протокол, то тут всё разложили по полочкам. > с сомнительными моментами Например? > и кучей опций Например? Какие «опции» являются лишними? > , не то чтобы удачной подборкой алгоритмов, рядом бестолковостей > и так далее. Если поинтересоваться вопросом - можно заметить что большинство > криптографов на такой протокол всерьез надеяться не собирается. Ну, лично я вообще не доверяю шифрованию, упирающуюся в факторизацию или дискретное логарифмирование. А следовательно нужно использовать либо известные и проверенные реализации проверенных пост-квантовых асимметричных алгоритмов (много таких знаете с поддержкой в ядре?), либо заморачиваться с распространением ключей для симметричной криптографии другими путями (что для большинства моих use case-ов является явно избыточным). Второе делается, но только для систем, работающих с ПДн. А первого мы ещё не скоро дождёмся в юзабельном для меня виде. И если дождёмся, то возможно как раз в IPSec-е. > Вообще, так модно козырять тем фактом что нечто - стандарт. И все > стандарты как на подбор то еще гэ с рядом проблем. Решение задачи напрямую исходит из формулировки самой задачи. Если стандартные средства более чем подходят, то зачем усложнять следующему сис. админу жизнь? По возможности, лучше использовать давно проверенные, хорошо изученные и всем известные средства. Естественно, существует тонна use case-ов, где приходится использовать всевозможные не-IPSec-и по объективным причинам, но есть всё-таки и тонна обратных use case-ов. > Вон тот же повсеместно пхаемый AES например имеет время выполнения зависящее от > ключа. Это позволяет туеву хучу атак косвенного восстановления ключей по анализу > времени выполнения алгоритма. Кто вас заставляет использовать AES в IPSec? > Всякие RSA и прочие - морально устарели. <sarcasm>Поэтому давайте считать RSA в HTTPS безопасным, а IPSec — нет.</sarcasm> > А получить представление о том как можно более-менее по людски делать шифрование > сетевых пакетов можно на примере cjdns какого-нибудь. Вся нагрузка на CPU при передаче трафика делается на уровне ядра? Если нет, то для моих use case-ов сразу в пень. > В десять раз проще, > минимум имения мозга пользователю «Программы могут работать в данной сети, при условии, что они поддерживают протокол IPv6.» , «Hyperboria является экспериментальной сетью, созданной тестерами и разработчиками cjdns для проверки протокола.» © https://ru.wikipedia.org/wiki/Cjdns Что-то мне кажется, что если вводить это в production, то имения мозга от программы и от начальства мне надолго хватит. Ещё люди бывает работают с филиалами, и лучше всего для объединения большого множества различных обособленных структур подходит что-то стандартизированное. Или, например, бывает L2TP over IPSec и т.п. Будете на android-ы ставить эти «cjdns»? Вообще, чего я распинаюсь? Вы просто привели в пример утилиту, решающую совершенно другую задачу. > , шустрая подборка алгоритмв и все лучшие свойства > которые можно ожидать от протокола с шифрованием. По дефолту. Без сотен > рычагов и кнопочек. И асимметрия, и пост-квантовость, и высокая производительность, и безопасность, и достаточно хорошая проверенность алгоритмов и их реализации, и поддержка на большинстве платформ и всё остальное? Не бывает универсального решения. Для каждой задачи своё решение (конечно, нередко эти решения пересекаются).